Hi David, On 05/12/2014 04:39 PM, David Sterba wrote: >> Because most modern hardware is 64 bit (with the exception of ARM ?), >> > could be make sense to allow btrfs to work without inode_cache only on >> > 64bit, loosing the possibility to be used on 32 bit system. >> > >> > Instead when the inode_cache is used, btrfs still be compatible with >> > both 32bit and 64bit systems. > There are 32bit machines in use and inode_cache brings some > compatibility assurance. Just that I would not recommend it to use by > default. > >> > How often a filesystem is moved between a 64bit and 32bit systems ? > Not so often I'd say, but for example the block device on a 32bit > machine can be exported via iscsi to a 64bit machine temporarily, then > the changes made on the 64bit host can make it unusable. 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. 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 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 ? [*] I means 32bit system were it is reasonable that btrfs would run. BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
