Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?20030110115728.GA16167>