Date: Wed, 02 Oct 2013 09:56:32 -0700 From: Sean Bruno <sean_bruno@yahoo.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-fs@freebsd.org Subject: Re: Endian issues, LE write to BE partitions Message-ID: <1380732992.6516.11.camel@localhost> In-Reply-To: <20131002164408.GB56872@funkthat.com> References: <1380730546.1619.47.camel@localhost> <20131002164408.GB56872@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-djOkgtXHBc5VCZFrmvcl Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wed, 2013-10-02 at 09:44 -0700, John-Mark Gurney wrote: > Sean Bruno wrote this message on Wed, Oct 02, 2013 at 09:15 -0700: > > Using makefs from an amd64 host to build a f/s in a VTOC8 partition wil= l > > destroy the entire partition table. I simplified the test to simple dd > > to an existing partition and got the same result, exonerating mkfs > >=20 > > I suspect a lack of endian knowledge in geom itself, not > > geom_part_vtoc8. =20 > >=20 > > test case: > > using amd64 host (10.0 current) create monolothic image > > truncate -s+5G /var/tmp/myfile.img > > mdconfig -f /var/tmp/myfile.img > > build and load geom_part_vtoc8 kernel module > > use gpart to create VTOC8 part table > > add partition to part table to yeild the following: > >=20 > > =3D> 0 10442250 md0 VTOC8 (5.0G) > > 0 10442250 1 freebsd-ufs (5G) =20 >=20 > This looks like a user error, or an issue that VTOC allows you to > create/write to a partition that covers the label metadata... So this > is most definately a VTOC8 issue... VTOC8 should at least return an > error when trying to write sectors that contain it's metadata.. >=20 Do you mean "user error" in that I personally executed a command that should not have been run or "user error" in that the geom_part_vtoc8 "user" should not allow me to dd to the partition? I suspect that on a g_write() from geom_part_vtoc8, the data is not be swapped around correctly. Should the geom_part_vtoc8 module be swapping the data in this case (writing from a LE machine to a BE f/s)? > newfs actually skips the first few KB of the disk because bsdlabels > would do the same thing... >=20 I would prefer to use newfs in this case actually, but it has no knowledge of how to write Big Endian f/s on Little Endian systems. Hence I was stuck with trying to use makefs in this case to get the f/s populated. Unless I'm mistaken, if I use newfs on this disk image from my amd64 host, it will get a little endian f/s. I'm assuming that this is part of my current problem. > This sounds like makefs is writing to the first few KB of the disk > unlike newfs which probably doesn't (because it knows it might be on > a partitioned disk and could destroy the partition table)... makefs, in this case, isn't really doing anything wrong here. Like dd, its using the target device as a destination for a file system creation. That's why I switched my test case over to dd, from makefs, for simplification of the problem. >=20 > > dd to md0a from dev zero for just a bit > > dd if=3D/dev/zero of=3D/dev/md0a bs=3D64k count=3D100 > >=20 > > destroy md0 via mdconfig -d -u 0 > > recreate it with mdconfig -f /var/tmp/myfile.img > >=20 > > gpart displays no partions for the image any more: > > gpart: No such geom: md0. > >=20 >=20 --=-djOkgtXHBc5VCZFrmvcl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSTFBAAAoJEBkJRdwI6BaHZy8H/31W9EX3qo8z8aGuGruDNFOD 7JuZPzPnHfchbih7McCJQ0+3OW09Svl2wuRUxir/G/A5ExM/2foTl0HAvkO6iky0 e/ciDzamg6lSt+oXkqmRAVyGhM17jg5KPTnpv4RA7hkDu0BRQ4nKAi6XuKk5ndsc fdGbRrLS230+6asgzRQPSCidvurBCSaYwxryY6Ck5pXmR70zvuOvl4u3Pa5RK+bN BJkIv75CJV8xneOUsYuapJz92aQ8vE0SnUOfM/YyfgyY3JumaEebNUXd9aZNPQtX prvAr1/p8oVuX+xwOF2gOYfmq73xiwBFJ+OqRb174mjwedWbzzjclr6QMrZAjfQ= =0Qk4 -----END PGP SIGNATURE----- --=-djOkgtXHBc5VCZFrmvcl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1380732992.6516.11.camel>