Re: Pending TrustedBSD stuff, etc.

From: Garance A Drosehn <gad_at_FreeBSD.org>
Date: Fri, 1 Jun 2007 23:12:18 -0400
At 7:19 AM +1000 6/2/07, Peter Jeremy wrote:
>On 2007-Jun-01 11:52:07 -0400, Garance A Drosehn <gad_at_freebsd.org> wrote:
>  >> - Peter Wemm has been talking about moving us to 64-bit inode numbers
>>
>
>>   I don't know at what level you mean to move to 64-bit inode
>>  numbers, but if (for instance) you meant a 64-bit value for st_ino,
>
>Since an inode number needs to fit into an ino_t, I would expect that
>ino_t and hence st_ino would both become 64-bit.

Well, I didn't know if Robert was talking about doing just the work
at the lower system levels, or just at the user-visible levels, or
both.  Given that I wasn't doing the work, I wanted to tread softly :-)

>  > then I'd also like to see a 64-bit value for st_dev at the same time.
>
>I can see the reason for having more than 2^32 inodes in a filesystem.
>It's not as obvious why you would need a 64-bit dev_t.  You're never
>going to have more than 2^32 devices attached to a system and I would
>suggest that it's unlikely that you would have more than 255 active
>drivers on one system.

With distributed filesystems such as OpenAFS, a 64-bit dev_t would
be very useful.  With OpenAFS, a single system can reference AFS
volumes from hundreds of sites, and each site can have tens of
thousands of separate AFS volumes.  Given the way AFS works, each
AFS volume would pretty much have to be a separate st_dev device.
(this has been gone over in previous discussions of stat changes...)

>What other struct stat changes are up for discussion?

I assume the timestamp-related ones.  Either for going to a 64-bit
time_t on the platforms we don't already have it (or at least
reserving the room for 64-bit time_t's), or maybe increasing the
resolution to sub-second.

Seems to me there were some others.  It might be better for us to
concentrate on getting to 7.0-RELEASE for now, and then open up the
discussion for what we'd want in 8.x-current once we're sure 7.x
has all the major problems worked out of it.

-- 
Garance Alistair Drosehn     =               drosehn_at_rpi.edu
Senior Systems Programmer               or   gad_at_FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA
Received on Sat Jun 02 2007 - 01:12:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:11 UTC