On 05/09/2014 04:51 PM, David Sterba wrote: > On Thu, May 08, 2014 at 04:22:13PM +0200, Tomáš Pružina wrote: >> I ran into some troubles with inode-cache rebuilding on root fs after >> filesystem was mounted without inode_cache, which stalls boot of my >> box by several minutes. >> >> I boot from commandline like: >> root=/dev/sda4 rootfstype=btrfs >> rootflags=inode_cache,space_cache,autodefrag rw ... >> >> However when I manually remount root fs without inode_cache (for >> example via kexec), it triggers cache rebuild at next mount which >> takes several tens of minutes and mimick 'freeze' on boot. >> >> Would it be possible to put some printk saying that this is happening >> so users don't get confused about it?? > > 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] 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. How often a filesystem is moved between a 64bit and 32bit systems ? [1] http://article.gmane.org/gmane.comp.file-systems.btrfs/9573 -- 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
