Re: Fwd: [suggestion] Add verbose notification about inode-cache rebuild to kernel log

[David Sterba <dsterba@suse.cz>]

On Mon, May 12, 2014 at 08:18:04PM +0200, Goffredo Baroncelli wrote:
> To be clear, I would like to avoid inode_cache on 64bit machine.
>
> In order to avoid the risk to exhaust the inode on 32bit and to be
> backward compatible with what already exists, we could add a flag to
> mkfs.btrfs to be only 64bit compatible and avoid inode_cache.

I thought about such bit as well but don't see a strong need for it, at
the moment the inode_cache is the only option that could prevent the
incompatibilities, but otherwise all features are designed to work on
32bits the same way as on 64bit.

So, my position here is not enforce anything, but document all the pros
and cons of the option and let the user decide.

Possibly, add more safety checks that would detect that a filesystem is
not safely mountable on 32bit. Eg. look for the highest inode num if
it's a 32bit system and inode_cache is not up-to-date, or warn early
that the inode space is running out.

> It it would be faster, I am sure that there are uses cases for that.
> 
> The major drawback that I see, is that it would be a code path less
> tested: I think that the 32bit system[*] would disappear soon

That's a valid point and for that reason I would not add more code.

> Finally I have a question: it is possible to disable inode_cache ?
> what means the flag "noinode_cache" ? It means disable the inode cache
> at all, or only avoid to store on disk the inode cache ?

The noinode_cache disables using the cache at runtime, it will be kept
on disk though (there's no "clear inode_cache" as for the space cache).