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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
