From owner-freebsd-current Fri Jan 10 3:57:35 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1434A37B401; Fri, 10 Jan 2003 03:57:34 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E0A743E4A; Fri, 10 Jan 2003 03:57:31 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0ABvS2G021653; Fri, 10 Jan 2003 03:57:29 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0ABvTOE016474; Fri, 10 Jan 2003 03:57:29 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0ABvSlJ016473; Fri, 10 Jan 2003 03:57:28 -0800 (PST) (envelope-from marcel) Date: Fri, 10 Jan 2003 03:57:28 -0800 From: Marcel Moolenaar To: Bruce Evans Cc: current@FreeBSD.ORG, gordon@FreeBSD.ORG Subject: Re: Superblock layout hosed on LP64 systems [was: Re: HEADS UP: VFS changes breaks GPT] Message-ID: <20030110115728.GA16167@dhcp01.pn.xcllnt.net> References: <20030109232943.GA1189@athlon.pn.xcllnt.net> <20030110204529.W20087-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030110204529.W20087-100000@gamplex.bde.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jan 10, 2003 at 08:58:21PM +1100, Bruce Evans wrote: > > Ok, after digging a bit I noticed that the super block layout > > has changed in a way that makes it incompatible with previous > > super blocks. It appears to be the alignment of fs_uuid on > > revision 1.36 of sys/ufs/ffs/fs.h. > > The trick of biting of bits of a char array to make non-char fields > often causes alignment problems and binary compatibility problems (see > mount.h...). I hope the CTASSERT will help out enough. I doesn't really catch field offset shifts that do not cause a struct size increase (by reusing implicit padding) if applicable. > > The following patch fixes the problem (and fixes the misuse of > > uuid for something that is not universally unique): > > > > Index: fs.h > > =================================================================== > > RCS file: /home/ncvs/src/sys/ufs/ffs/fs.h,v > > retrieving revision 1.36 > > diff -u -r1.36 fs.h > > --- fs.h 8 Jan 2003 22:53:54 -0000 1.36 > > +++ fs.h 9 Jan 2003 23:23:28 -0000 > > ... > > @@ -311,7 +311,8 @@ > > int8_t fs_old_flags; /* old FS_ flags */ > > u_char fs_fsmnt[MAXMNTLEN]; /* name mounted on */ > > u_char fs_volname[MAXVOLLEN]; /* volume name */ > > - u_int64_t fs_uuid; /* system-wide unique uid */ > > + u_int64_t fs_swuid; /* system-wide unique id */ > > This change has rotted in the committed version. The comment still > says "uid" and doesn't say "unique", but the id is even less of a user > id than it is universally unique. The "u" in "fs_swuid" is confusing > too. I suppose it's too late to remove the "u"s from "uuid" so that > it doesn't look like "uid" :-). I searched the mailinglists and it appears to me that the intention really is that it's an UUID. Consequently, the bug is that fs_uuid has not been given type struct uuid. The alignment requirements of struct uuid are such that you only need another 4 bytes and you would eliminate fs_pad. Plus you get to use existing functionality. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message