Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

[Miklos Szeredi]

> > The legacy app will break regardless of how many files there are on
> > the filesystem, or even wheter it needs to use the inode number or
> > not.  It will break because the stat() family of syscalls will return
> > with an error.
> 
> I don't see why.  The kernel should be able to tell whether the app
> has called the old (smallfile) stat function, or the new stat
> function.  If the app calls the old stat function, the kernel can give
> it a 32-bit inode number.  If the app calls the new stat function, the
> kernel can give it a 64-bit inode number.  The two inode numbers do
> not have to agree.

There's also glibc in between the kernel and the app.  In fact the
EOVERFLOW error is generated by glibc, not the kernel.  The kernel
just quietly truncates the inode number AFAICS.

If you were thinking of a soltuion, where the filesystem itself
supplies two different inode numbers based on the variant of the
userspace interface, then I'm sorry to inform you, that this sort of
interface is not likely to happen in the Linux kernel.

If you were thinking of automatically converting a 64bit inode number
to a 32bit one (e.g. truncating it), that may be OK, I don't know why
glibc is more paranoid than the kernel in this respect.

However, I realized that inode numbers generated by hashing the path
have another fatal problem.  Namly that if you rename a file or
directory, then the inode number will of course move with the name,
but after that the stability of the number is not any more guaranteed.
It's back to where we started, only with a more complex scheme.

> This is not a perfect solution (for example, a smallfile legacy app
> can't print an inode number and give it to a modern app), but it's
> good enough.  Failure modes will be quite rare and easily explained,
> just as they're explained for the 2 GiB limitation on smallfile legacy
> aps (a problem that's considerably more important).
> 
> > it is _NOT_POSSIBLE_ to make these filesystems conform to POSIX.
> 
> Sure it is.  All it takes is sufficient resources.  You could maintain
> an auxiliary inode table outside the file system, for example.

And this could be an ever growing table, as the filesystem may not be
aware of any removals on the server end.

> But I'm trying to help generate a solution that's more efficient
> than that, one that is "good enough" to support the obsolescent
> software you're worried about.

Cool.  Still waiting for the breakthrough :)

Miklos