Re: Link count for directories

["Chris Mason" <clm@fb.com>]

On 25 Aug 2020, at 8:37, Nikolay Borisov wrote:

> On 25.08.20 г. 1:23 ч., Adam Borowski wrote:
>> On Mon, Aug 24, 2020 at 11:50:30PM +0200, Steve Keller wrote:
>>> Nikolay Borisov <nborisov@suse.com> wrote:
>>>> I have implemented it so it's not that big of a deal. However turns 
>>>> out
>>>> it has pretty steep requirements for backport because so far btrfs
>>>> always kept the link count of dirs to 1.
>>
>>>> So how effective is such an optimisation to the software using it ?
>>>
>>> It's not only optimization like in find(1).  As an old and long-time 
>>> Unix
>>> user I'd also like that traditional behavior.  It just feels more 
>>> correct
>>> since if you do mkdir ./a ./b ./c ./d, you will actually see the 4 
>>> links
>>> to the current dir if you do ls -ai a b c d and the two links from . 
>>> itself
>>> and from ..
>>
>> It's just an implementation detail of sysvfs, and a case of
>> bug-compatibility.  The link count of a directory is always 1 as 
>> btrfs,
>> ext4, xfs, etc -- none of them support directory hardlinks, unlike 
>> sysvfs.
>
> Wrong, ext4 and xfs do  maintain the count.

Correct, at least until they hit 65536.  It’s some weird special case 
handling for an optimization I didn’t see applications really using, 
so I just with with a fixed link count of one.  Find certainly paid 
attention, but from an optimization point of view, dtype in directory 
entries is dramatically more helpful.

I’d want to see big wins from applications before adding this into 
btrfs.

-chris