From owner-freebsd-geom@FreeBSD.ORG Thu Mar 13 00:12:34 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC16C1065671 for ; Thu, 13 Mar 2008 00:12:34 +0000 (UTC) (envelope-from dwiest@vailsys.com) Received: from cprobd02.vailsys.com (cprobd02.vailsys.com [63.210.102.130]) by mx1.freebsd.org (Postfix) with ESMTP id 99F888FC14 for ; Thu, 13 Mar 2008 00:12:34 +0000 (UTC) (envelope-from dwiest@vailsys.com) Received: from dpfuser01.vail (dpfuser01.vail [192.168.129.103]) by cprobd02.vailsys.com (Postfix) with ESMTP id DBDBDCE667 for ; Wed, 12 Mar 2008 19:12:33 -0500 (CDT) Received: from dfwdamian.vail (dfwdamian.vail [192.168.129.233]) by dpfuser01.vail (Postfix) with ESMTP id D7BC25C5A for ; Wed, 12 Mar 2008 19:12:32 -0500 (CDT) Received: (from dwiest@localhost) by dfwdamian.vail (8.13.8/8.13.8/Submit) id m2D0CWGG089247 for freebsd-geom@freebsd.org; Wed, 12 Mar 2008 19:12:32 -0500 (CDT) (envelope-from dwiest@vailsys.com) X-Authentication-Warning: dfwdamian.vail: dwiest set sender to dwiest@vailsys.com using -f Date: Wed, 12 Mar 2008 19:12:32 -0500 From: Damian Wiest To: freebsd-geom@freebsd.org Message-ID: <20080313001232.GL32089@dfwdamian.vail> References: <20080307230058.GA8902@keira.kiwi-computer.com> <20080308024954.GF15859@dfwdamian.vail> <20080308064455.GA13341@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080308064455.GA13341@keira.kiwi-computer.com> User-Agent: Mutt/1.4.2.3i Subject: Re: geom_vinum platform-independent brokenness X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2008 00:12:34 -0000 On Sat, Mar 08, 2008 at 12:44:55AM -0600, Rick C. Petty wrote: > On Fri, Mar 07, 2008 at 08:49:54PM -0600, Damian Wiest wrote: > > > > So you're saying that you should be able to remove a disk (or set of disks) > > from an x86 system, install it in a system running the amd64 release and > > have things just work? > > That is the plan. At work, we have a couple of machines on which we wanted > to try amd64, but couldn't boot since the root fs is in gvinum. It makes > sense for people who want perhaps to dual boot or otherwise want to migrate > their data. > > > I would imagine that most people would simply use > > dump/restore, but I agree that it would be nice if one didn't have to do > > this. > > That solution obviously requires twice the disk space. It's especially > worse if you're using RAID5. At home I'm considering upgrading to amd64 > (since it's only a file server), but I don't have 4 TB of spare disks lying > around for the migration. > > > How is this scenario handled for basic disks? > > I'm not sure I understand your question. I was just thinking of the simplest case where the disk you're moving used a bsdlabel. > > Can an amd64 system > > handle a disk that was labeled on an x86 system? > > No, that was exactly the problem I am describing. It noticed that there > were vinum disks, but the configuration was all screwed up. > > > I haven't ever tried > > this, but the manpage for bsdlabel suggests that it won't work unless > > you originally wrote an amd64 label by using the -m option. > > I'm not talking about the disklabel here. geom_vinum takes up the first > 265 sectors (512 bytes each) to store its configuration. These are > straight-up disks that aren't needed in Windoze or other OS-- just plain > FreeBSD, so we use the full disks without labels or MBR partitions. Right. I was just wondering what would need to be changed when moving a bsdlabeled disk from x86 to amd64 or vice-versa. I was thinking that if the labels (both bsdlabel and gvinum's) were padded a bit at the end (so you don't clobber any real data), then one could simply rewrite the label once the disk was moved to the new system. My thinking was that it might be simpler to allow the label to be rewritten with some utility versus modifying how gvinum interprets labels. > > Aren't you going to run into issues with your filesystems when moving > > from one architecture to another that uses a different bus width? > > How so? Are you saying there are bugs in UFS which will prevent this from > working? If so, this is a much bigger problem than I anticipated. Looking > at sys/ufs/ffs/fs.h, I do see a bunch of pointers in the superblock > structure ("struct fs"), but all other superblock fields and other on-disk > structures have fixed size values. Also there's a sanity test on the size > of the "struct fs". Someone clearly has thought of this problem > (McKusick ?). After some minimal testing of mounting i386-created UFS2 > volumes on amd64, everything seems to work just fine. > > I've also investigated geom_mirror, and the on-disk structure seems clean. > There may be others that are broken, but geom_vinum is what I've noticed > and that is what I intend to fix. If UFS *is* broken, it should be fixed > also. > > Thank you for reminding me to test the filesystem! > > -- Rick C. Petty No, I wasn't saying anything about UFS in particular. Just that you'll also want to consider the underlying filesystems and not just the gvinum bits. -Damian