Roman Mamedov posted on Tue, 21 Oct 2014 16:16:11 +0600 as excerpted: > On Tue, 21 Oct 2014 09:50:37 +0000 (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> (FWIW I wish that mount option would just go away as it would >> definitely remove an invitation to a Russian roulette party with their >> data for the unwary, but I suppose there's someone paying some bills >> somewhere that wants it kept for some specific use-case where the >> performance gain must be worth the calculated risk, thus continuing >> that invitation to data Russian roulette for everyone else.) > > Why do you think it is so dangerous? Just because of possible bugs? But > bugs can be anywhere in Btrfs, why specifically single out one mount > option. > > Let's take a look at its description in the wiki: > > "inode_cache (since 3.0) > Enable free inode number caching. Not recommended to use unless files on > your filesystem get assigned inode numbers that are approaching 2^64. > Normally, new files in each subvolume get assigned incrementally (plus > one from the last time) and are not reused. The mount option turns on > caching of the existing inode numbers and reuse of inode numbers of > deleted files. > This option may slow down your system at first run, or after mounting > without the option." > https://btrfs.wiki.kernel.org/index.php/Mount_options > > As you can see it's not about performance, but rather more of a > recognition that a filesystem with some pre-determined finite lifetime > expectancy is not a good thing to have; even though 2^64 is a lot, there > are various scenarios out there, including millions of files and > constant creation and removal of snapshots, that may make the FS hit the > limit faster than you would expect.
inode_cache is generally not needed on 64-bit, and it is known to cause problems on 32-bit where a cache overflow and non-unique cached inode- numbers is possible on large filesystems, as well as boot-time slowdowns (including timeouts on mounting, for filesystems mounted at boot) on 64- bit. I guess the real trouble is that the problems with it aren't well documented and relatively few people know about them, mostly regulars on this list, so people end up enabling it even on 64-bit where about the only effect is a boot-time slowdown and the increased chance of crash- corruption of yet another cache, as well as on 32-bit where it's actually useful if somewhat risky (especially for large filesystems), thus getting themselves in needless trouble. If there was a big IF YOU USE THIS AND IT GOES BAD YOU GET TO KEEP THE PIECES warning on it, I guess fewer people would use it, but then people would be asking questions about why it's there in the first place. And I don't know why, as I've only seen it cause needless problems, never actually help, and I know that everyone here recommends turning it off without any exception I've seen. But the conspiracy theory side of me says if it's causing problems and not helping, and it's still there, there must be a reason... -- 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
