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). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
