Szőts Ákos posted on Tue, 03 Dec 2013 12:28:26 +0100 as excerpted: > Dear list members, > > I'm not sure if this a bug or an intended behaviour, since I've yet to > find a reliable source with Google search. > > My problem is the following: with the 3.12 kernel on every single boot > (even when the computer was shut down clear) the process > [btrfs-ino-cache] is preventing the successful startup of X because it's > running for 6 minutes. > > I can see this in "iotop" and while that program runs the whole system > is being blocked. After 6 minutes I restart X and everyting goes normal > from that point on. > > My question is: is that necessary to regenerate the inode cache on every > boot or is this a bug? Of course if I remove the "inode_cache" option > from fstab, this phenomenon disappears. > > Versions: > - OS: openSUSE 13.1 - Kernel: 3.12.0-6.ge7c00d8-desktop #1 SMP PREEMPT > Tue Nov 12 13:09:24 UTC 2013 (e7c00d8) > - Mount options: compress=lzo,space_cache,inode_cache,noatime
>From what I've seen (as a btrfs using admin and list regular, /not/ a dev, btrfs or otherwise), the inode_cache mount option isn't intended or recommended for general purpose use. Its intended purpose is, I believe, for cases such as mail servers, for example, where a sluggish startup isn't a big issue, but where quickly and efficiently creating/deleting lots of little files is part of the job description. The general recommendation thus appears to be to omit the inode_cache mount option unless your use-case requires it, and the X-based user desktop use-case almost certainly doesn't. Meanwhile, briefly on the other options: While continuous use of the space_cache option won't hurt anything, it really only needs turned on once, after which it's on permanently unless you specifically disable it again. Noatime's a good choice on most filesystems, but especially btrfs if you're using snapshotting (as I believe OpenSuSE makes heavy use of), so good choice there. And I'm using compress=lzo here too. =:^) You may wish to consider adding autodefrag also, altho if you've not been running with it from the beginning, performance may be bad for awhile until it has caught back up with existing fragmentation, but then it should be better. One way around that is to defrag (or rebalance, which rewrites everything and thus defrags in the process) everything, which could take awhile on a multi-terabyte spinning-rust drive, then mount with autodefrag from then on, to avoid heavy fragmentation happening again. That used to require a rather convoluted command, but a new enough btrfs-progs and kernel should let you use the btrfs filesystem defrag -r (recursive) option. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
