On Fri, May 09, 2014 at 08:12:54PM +0200, Goffredo Baroncelli wrote: > > Adding the printk is probably a good thing, but I'd rather reconsider > > using inode_cache at all. IMO it's supposed to fix problems with inode > > numbers that we don't have. > > IIRC, the problem is for the 32 bit system, were the API wants the inode > number to be 32 bit.. > > In the past the inode_cache was introduced because the inode often reached > 2^32 [1]
Right, it makes sense for the 32bit case under some circumstances. However I don't see where's "often reached 2^32" mentioned in the link. If it's really 'often', then there's something wrong. A 32bit machine serving large amounts of files? Or, it could reach the limit over time, say a few years, so I'm not saying it can't happen in practice. Then, inode_cache is the workaround for this usecase and can be turned on if things are going to be bad. Another workaround, that requires more manual intervention, is to create a new subvolume and reflink all the files there. > 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. Thanks for the pointer, I think this is a documentation issue, we can keep inode_cache code as-is. -- 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
