Date: Tue, 12 Mar 2002 10:12:53 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Terry Lambert <tlambert2@mindspring.com>, Harti Brandt <brandt@fokus.gmd.de>, Robert Watson <rwatson@FreeBSD.ORG>, Julian Elischer <julian@elischer.org>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <p05101551b8b3c1f14df9@[128.113.24.47]> In-Reply-To: <60373.1015917340@critter.freebsd.dk> References: <60373.1015917340@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 8:15 AM +0100 3/12/02, Poul-Henning Kamp wrote:
>In message , Garance A Drosihn writes:
>
>>So, as far as userland stat() goes, a 64-bit inode is pretty
>>easy, but I would like to see us set the stage for the other
>>things we keep talking about. All of those require a bigger
>>struct-stat, and I can't think of any pretty way of doing
>>that and also maintaining binary compatibility.
>
>... as I keep telling you :-)
Yeah, well, I kept hoping I could think up some super-clever
magic, but it just wasn't happening...
>A new size for struct stat is part of the UFS2 effort, in fact
>I'm on the ball to do that bit. The new struct stat will be
>big enough that we can expand all relevant fields.
>
>UFS2 is aimed at 5.0 if at all possible.
>
>So please relax, things are happening.
Sounds good!
Now for suggestion part #2:
Once we get to a 64-bit (u)dev_t, we could reserve one byte of
that for the "type of filesystem" (loosely speaking). A value
of 0 for local hard disks
1 for NFSv2-mounted
2 for NFSv3-mounted (maybe this isn't necessary...)
3 for OpenAFS or ARLA mounted
4 for CODA-mounted
5 for something appletalk-ish, if we ever did that
6 for something netware-ish, if we ever did that
This way, any one system could choose whatever method it wants
to build the rest of the dev_t entry, and it knows it can not
conflict with the dev_t values that would be generated by any
other major filesystem type.
I expect we could collapse the first three into a single
value. It's mainly when we get to global filesystems that
I think we want to be sure that we can use the "global ID"
for a volume without worrying about conflicts with dev_t's
generated by anything on the local machine. The local
machine will have no control over those global ID's, and yet
it would be nice to be able to directly use them.
Yeah, this is probably another case of me stating the obvious,
but still I wanted to mention it. This way Julian can pick
whatever dev_t-generating method which works best for local
hard disks, and not care what values might appear for OpenAFS
or CODA.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101551b8b3c1f14df9>