Date: Fri, 10 Jan 2003 03:57:28 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Bruce Evans <bde@zeta.org.au> 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> In-Reply-To: <20030110204529.W20087-100000@gamplex.bde.org> References: <20030109232943.GA1189@athlon.pn.xcllnt.net> <20030110204529.W20087-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030110115728.GA16167>