Re: number of hardlinks for directory in ls -lid always 1?

[Filipe David Manana <fdmanana@gmail.com>]

On Fri, Mar 20, 2015 at 12:39 PM, David Sterba <dsterba@suse.cz> wrote:
> 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@suse.cz> 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.

Maybe this was all before delayed inodes were introduced, where
updating inode items always implied touching the btrees.



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."