Date: Thu, 25 Aug 2011 07:49:32 -0400 From: John Baldwin <jhb@freebsd.org> To: mdf@freebsd.org Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r225154 - in projects/ino64/sys/ufs: ffs ufs Message-ID: <201108250749.32660.jhb@freebsd.org> In-Reply-To: <CAMBSHm8H8mzAvBSNmi4_wVYqxJNrxT3hGiJH9WL3u4Hr6UmdSg@mail.gmail.com> References: <201108242214.p7OMEuMP072758@svn.freebsd.org> <CAMBSHm8H8mzAvBSNmi4_wVYqxJNrxT3hGiJH9WL3u4Hr6UmdSg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, August 24, 2011 7:09:24 pm mdf@freebsd.org wrote: > On Wed, Aug 24, 2011 at 3:14 PM, Matthew D Fleming <mdf@freebsd.org> wrote: > > Author: mdf > > Date: Wed Aug 24 22:14:55 2011 > > New Revision: 225154 > > URL: http://svn.freebsd.org/changeset/base/225154 > > > > Log: > > Use fixed-width types in on-disk structures. This takes care of all the > > ino_t references I could find that were on-disk. > > > > GSoC r223157. > > Code by Gleb Kurtsou. > > Note that I've explicitly left all the XXXfid structs alone; when > ino_t is changed to 64-bit they will use 64-bit members for inode > number. The only in-tree one that may be a problem is ReiserFS which > will have a 32 byte FID after compiler padding is applied. This can > be reduced to 24 bytes by reordering the members. In theory, IIRC, > even 32 bits is an okay FID, however I have seen a note at $WORK that > NFSv2 has 32 byte file handles and BSD is using 8 bytes for the fsid. > > If anyone knows anything more, please let me know. For the moment I > think my plan is to re-order the members of various implementations to > keep them smaller, and leave it as an ino_t in the struct definition. One suggestion I do have in regards to this branch. Earlier there was a request to increase the userland dev_t to 32-bits. The primary user of this would seem to be OpenAFS. Gleb did not agree to do this, but I actually think we should go ahead and bump dev_t. Changing for the layout of stat is a lot of work and I'd rather err on the side of being too future proof than deciding 2 years from now "gee, we really could have used a bigger dev_t". -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108250749.32660.jhb>