[rfc] 64-bit inode numbers

[Garance A Drosehn]

On 6/23/11 4:11 AM, Kostik Belousov wrote:
> On Thu, Jun 23, 2011 at 09:43:33AM +0300, Gleb Kurtsou wrote:
>    
>> On (22/06/2011 19:19), Garance A Drosehn wrote:
>>      
>>> Sorry for replying to an older message, but a reply made in a different
>>> thread reminded me about this project...
>>>
>>> Also, I may have asked this before.  In fact, I'm almost sure that I started
>>> a reply to this back in Jan/Feb, but my email client claims I never replied
>>> to this topic...
>>>
>>> Are you increasing only the size of ino_t, or could you also look at
>>> increasing the size of dev_t?   (just curious...)
>>>        
>> Sure. Incorporating as much of similar changes as possible is good.
>> I've added Kostik and Matthew to CC list, it's for them to decide.
>>
>> dev_t on other OSes:
>> 	NetBSD - uint64_t
>> 	DragonFly - uint32_t
>> 	Darwin - __int32_t
>> 	OpenSolaris - ulong_t
>> 	Linux - __u32
>>
>> Considering this I think 3rd party software is not ready for such
>> change.
>>
>> Major/minor mapping to dev_t will get more complicated.
>>
>> And the most important question: what would you want it for? [...]
>>      
> Indeed, this is the right question.
>    
Consider the thread "Increasing the size of dev_t and ino_t" from
freebsd-arch in 2002:

http://docs.freebsd.org/mail/archive/2002/freebsd-arch/20020317.freebsd-arch.html

In particular, this message by Robert Watson:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=139853+0+archive/2002/freebsd-arch/20020317.freebsd-arch

I just participated in an online conference for OpenAFS, and while it
isn't exactly taking the world by storm, I keep thinking it would be
useful if FreeBSD could map individual AFS volumes to unique dev_t
identifiers.  And given the way AFS is implemented (as a global filesystem
with many cells all reachable at the same time), and given the way most
sites deploy AFS (with thousands or tens-of-thousands of individual AFS
volumes *per site*), that adds up to a lot of values for dev_t.

The upcoming release of OpenAFS should include a working and pretty
stable AFS client for FreeBSD, so having a larger dev_t would have a
more immediate application than it did back in 2002.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu