On Thu, Mar 19, 2015 at 09:47:15PM +0000, Filipe David Manana wrote: > 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. I wonder why the link count is not maintained then. The directory inode is modified anyway, add a few ifs here and there will not make things worse and we could get rid of this special behaviour, plus find could use the link count reliably. It can be turned on in a fully backward compatible way: * new directories/subvolumes will get dir nlink set to 2 * if mkdir/rmdir/move sees a parent link count of 1, no change * otherwise inc/dec the link count for new subdirectoris/subvolumes Jeff Liu reported a problem, without further details http://article.gmane.org/gmane.comp.file-systems.btrfs/14628 so I still might be missing something. -- 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
