[rfc] 64-bit inode numbers

[Bruce Evans]

On Thu, 23 Jun 2011, Rick Macklem wrote:

> Kostik Belousov wrote:
>> On Thu, Jun 23, 2011 at 06:05:56PM -0400, Garance A Drosehn wrote:
>>> 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.
>> Am I right that the issue is the uniqueness of the dev_t for each
>> AFS volume, as reported by stat(2) ?
>>
>> Shouldn't the AFS client synthesize the dev_t for each new volume
>> mounted ? It seems that the current 32bit dev_t would be enough,
>> since I do not expect to see hundreds of thousands of mounts
>> on an single system.
>>
> I think the main concern is making sure that the value is not the
> same as what another mount already has. That's why mnt_stat.f_fsid
> is synthesized for NFS, I think?
>
>> Please note that we do not guarantee dev_t stability across reboots
>> even
>> for real devices.

mnt_stat.f_fsid is generated from the dev_t, and tries to give stability
across reboots.  Otherwise, IIRC, nfs mounts break if the server is
rebooted.  Not only the dev_t part, but other things in f_fsid, depend
on the order of initialization, but the ids usually end up the same if
you don't reconfigure much on the server.

f_fsid also has a problem with uniqeness, but that is mainly because it
wants to be unique when truncated to a 16-bit dev_t.  dev_t is only 16
bits in some versions of Linux, including in the FreeBSD i386 Linux
emulator (I can see traces of 32-bit dev_t in Linux-2.6.10 but not in
the FreeBSD emulator).

I hope AFS ids could be implemented like fsids and not need to literally
match foreign ids, but if they are synthesized then they might be harder
than fsids to keep invariant across reboots.

Bruce