Swami,
I believe the only thing that "inode_cache" mount option does is
allowing to reuse inode numbers. Like if you had a file with inode
number=X and you delete this file, then you will never have inode=X in
the same file tree (subvolume) again. You can look at
btrfs_find_free_ino() that allocates an inode number to understand
this better. Since inode number is u64, it is perhaps unlikely that
you ever run out of inode numbers. But still this mount option is
present and implemented, so perhaps there is some reason for that.
You can also look at "Free space cache writeback issue" note from Jan
on the list; looks like he discovered some issue with that option.
Alex.
On Sun, Oct 14, 2012 at 1:24 PM, Swâmi Petaramesh <swami@petaramesh.org>
wrote:> Hi there,
>
> On a performance standpoint - and on Ubuntu Quantall kernel 3.5.0-17 -
> is it advisable to mount BTRFS with "inode_cache" ?
>
> Is there any risk or counterpart doing so ?
>
> TIA, kind regards.
>
> --
> Swāmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP
9076E32E
> Ne cherchez pas : Je ne suis pas sur Facebook.
>
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html