Endian issues, LE write to BE partitions

[Sean Bruno]

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.
> > 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20131002/5a62008e/attachment.sig>