Re: 64-bit inode numbers (was: glibc 2.1.96)

["H. Peter Anvin" <hpa at transmeta dot com>]

I have Cc:'d this to the linux-fs-devel list; hopefully we can get some
communication going.

Mark Kettenis wrote:
> 
>    I believe I wrote this back as well: this will affect *ALL* applications,
>    even those that don't need large file support.  This change really needs
>    to happen, or any non-LFS application is DANGEROUS AND UNUSABLE.
> 
> Which would imply that all existing non-LFS Linux binaries are
> DANGEROUS AND UNUSABLE.  If that's really true, we (both glibc and
> kernel developers) should think a bit harder how to solve this.
> 

This is true.  You're right; we seems to have backed ourselves into a
pretty tight corner.

Recap:

1. Some filesystems seem to require a 64-bit inode number.  Especially
nfs v3/v4 makes this very hard to circumvent, but even some local
filesystems (SGI XFS, for example, or UDF.)

2. glibc currently uses a 32-bit ino_t.

3. We have discussed -- especially at OLS -- various workarounds in the
kernel; however, it does appear to be an insoluble problem unless the
kernel devotes memory to maintaining information about every inode ever
seen.  This is especially so when it comes to programs that use dev/ino
pairs to detect hard links -- a very common operation.

4. Obviously, a switch to LFS (or, equivalently, to using large types by
default!) resolves this problem as well as many others.  However, this
would appear to require a new major revision of the library. 
(Incidentally, if we ever do that, we probably need to reconsider the #1
problem we had during the libc5->6 transition: the inability to detect if
another library was compiled to the libc5 or libc6 ABI; making it
impossible for the dynamic linker to pick the correct version of the
other library most of the time.  During libc4->5 this was trivial, since
they were completely different binary formats.)

5. According to Ulrich, symbol versioning isn't powerful enough to let us
rev the type of ino_t.

6. Either way, existing binaries cannot handle stat() on 64-bit inode
filesystems.

Ideas, anyone?

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt