Re: Link count for directories

Nikolay Borisov
2020-08-25T12:37:33Z

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.

>
> So the proper value, as documented, is 1. Copying sysvfs behaviour is also
> costly as you need to know the count of contents while statting parent.
>

Turns out it's not costly at all at least implementation wise. However
it incurs a significant cost on maintainability because progs needs to
be modified because they'd think a filesystem with a directory count
different than 1 is broken... So really the pros need to outweigh the cons.

>
> Meow!
>