Re: Link count for directories

[Nikolay Borisov <nborisov@suse.com>]

On 25.08.20 г. 0:50 ч., 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 such a change should be
>> justifiable because it's not only the kernel code that is affected but:
>>
>> 1. Backporting relevant patch to older, stable kernels
> 
> Why would that be needed?

So what happens when a new filesystem (i.e one created with a kernel
with this features) gets mounted on an older kernel (one that doesn't
support it)? (It's a rhetorical question, it will refuse to mount
because of the tree checker).

> 
>> 2. Changing btrfs-progs so that it doesn't erroneously think a kernel
>> with link count larger than 1 is broken.
> 
> OK, should be doable, right?

I never said it wasn't, however the question is if it's worth it doing
that work.

> 
>> 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 ..
> 
> Steve
>