Date: Wed, 2 Oct 2013 10:16:33 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: sbruno@freebsd.org Cc: freebsd-fs@freebsd.org Subject: Re: Endian issues, LE write to BE partitions Message-ID: <20131002171633.GD56872@funkthat.com> In-Reply-To: <1380732992.6516.11.camel@localhost> References: <1380730546.1619.47.camel@localhost> <20131002164408.GB56872@funkthat.com> <1380732992.6516.11.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Bruno wrote this message on Wed, Oct 02, 2013 at 09:56 -0700:
> 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?
user error in that you created a partition that covered the metadata and
a bug in vtoc8 that allows you to overwrite it while you hold it's child
parition open for writing..
If you instead started the partition you created at 0, if you added
a -b 16 to your gpart add, you'd skip over the vtoc8 meta data in the
first sector and your dd wouldn't overwrite it...
> 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)?
Nothing to do w/ BE or LE...
> > 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.
The first statement is correct, the last is not.. there are no edian
issues that I see yet...
> > 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.
except it behaves differently from newfs...
> > > 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.
See my script of doing it (though I'm not sure why -b 16 starts it at
16065):
# truncate -s+5G myfile.img
# mdconfig -t vnode -f myfile.img -a
md0
# kldload geom_part_vtoc8
# gpart create -s vtoc8 /dev/md0
md0 created
# gpart add -t freebsd-ufs -b 16 /dev/md0
md0a added
# gpart show /dev/md0
=> 0 10442250 md0 VTOC8 (5.0G)
0 16065 - free - (7.8M)
16065 10426185 1 freebsd-ufs (5.0G)
# dd if=/dev/zero of=/dev/md0a bs=64k count=100
100+0 records in
100+0 records out
6553600 bytes transferred in 0.402172 secs (16295512 bytes/sec)
# mdconfig -d -u 0
# mdconfig -a -t vnode -f myfile.img
md0
# ls /dev/md0*
/dev/md0 /dev/md0a
# gpart show /dev/md0
=> 0 10442250 md0 VTOC8 (5.0G)
0 16065 - free - (7.8M)
16065 10426185 1 freebsd-ufs (5.0G)
See, the vtoc8 partition survived...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131002171633.GD56872>