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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 will > > destroy the entire partition table. I simplified the test to simple dd > > to an existing partition and got the same result, exonerating mkfs > > > > I suspect a lack of endian knowledge in geom itself, not > > geom_part_vtoc8. > > > > 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: > > > > => 0 10442250 md0 VTOC8 (5.0G) > > 0 10442250 1 freebsd-ufs (5G) > > 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.. > 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... > 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. > > > dd to md0a from dev zero for just a bit > > dd if=/dev/zero of=/dev/md0a bs=64k count=100 > > > > destroy md0 via mdconfig -d -u 0 > > recreate it with mdconfig -f /var/tmp/myfile.img > > > > gpart displays no partions for the image any more: > > gpart: No such geom: md0. > > > [-- Attachment #2 --] -----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-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1380732992.6516.11.camel>