inode_cache Re: strange 3.16.3 problem

[Roman Mamedov <rm@romanrm.net>]

On Tue, 21 Oct 2014 09:50:37 +0000 (UTC)
Duncan <1i5t5.duncan@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.

-- 
With respect,
Roman