From owner-freebsd-fs@FreeBSD.ORG Wed Oct 2 17:16:35 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 452CFBE3; Wed, 2 Oct 2013 17:16:35 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1AE4029FB; Wed, 2 Oct 2013 17:16:34 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r92HGXwt094627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Oct 2013 10:16:34 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r92HGXeq094626; Wed, 2 Oct 2013 10:16:33 -0700 (PDT) (envelope-from jmg) Date: Wed, 2 Oct 2013 10:16:33 -0700 From: John-Mark Gurney To: sbruno@freebsd.org Subject: Re: Endian issues, LE write to BE partitions Message-ID: <20131002171633.GD56872@funkthat.com> References: <1380730546.1619.47.camel@localhost> <20131002164408.GB56872@funkthat.com> <1380732992.6516.11.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1380732992.6516.11.camel@localhost> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 02 Oct 2013 10:16:34 -0700 (PDT) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:16:35 -0000 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."