Filipe David Manana <fdmanana@xxxxxxxxx> schrieb: > On Thu, Mar 19, 2015 at 1:21 PM, David Sterba <dsterba@xxxxxxx> wrote: >> On Wed, Mar 18, 2015 at 03:23:50PM +0100, Martin Steigerwald wrote: >>> It explains that having a correct hardlink number for directory is not >>> mandatory, but it doesn´t explain why BTRFS always has 1 in there >>> instead of the actual count of hardlinks. Is this an performance >>> optimization for BTRFS or are there any other reasons why BTRFS does it >>> this way? >> >> I believe it's for performance reasons. New inodes do not update the >> parent directory metadata wrt link counts, compared to other filesystems >> that do that. > > Weird. Because creating a new inode implies adding the dentry to the > parent directory, which implies updating the directory's i_size. Maybe related to snapshots? Which brings us back to COW and performance: >> The real performance hit could be noticeable. The directory inode is >> cached in memory, so first update would be a bit slower, but the >> metadata block needs to be cow-ed on each new file. It's stress on >> b-tree locking and allocating new buffers for the metadata blocks. >> -- >> 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 > > > -- Replies to list only preferred. -- 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
