Re: [RFC] st_nlink after rmdir() and rename()

[Linus Torvalds]

On Wed, Mar 2, 2011 at 10:03 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> IOW, it's a QoI question - sure, NFS is weird and you lose a lot of usual
> warranties there when it comes to object removal.  But why get local
> fs behaving strangely?  It's not like "decrement i_nlink from 2 to 1" was
> cheaper than "assign 0 to i_nlink", after all.
>
> FWIW, a lot of local filesystems have no notion of links; they tend to
> maintain zero/non-zero distinction just fine.  Including those that have
> all directories with i_nlink == 1 for as long as directory lives.

The thing is, I don't think it's a QoI question at all - since any
user that _depends_ on this kind of behavior is simply broken. We
aren't going to guarantee it, exactly because some filesystems simply
will not ever guarantee it.

Now, for FAT we do in fact try rather hard to fake the i_nlink count,
but I'm not at all convinced that's a good idea. It makes reading
directory inodes on FAT much more expensive (we have to basically do a
readdir for each open). So I'd hate to make that whole "you need to
emulate i_nlink even if you really don't care" be something that we
actually end up thinking is a quality issue.

There are other filesystems where i_nlink can be even _less_
meaningful, ie if the filesystem does any kind of fancy
content-indexing thing or lazy COW (think "union filesystem within the
filesystem") or whatever, I could easily see i_nlink not having any
traditional unix filesystem semantics.

Seriously - how did you even notice this?

I'm not opposed to fix actual bugs, but I _do_ think it is
questionable to make this kind of nonsense semantic issue be an issue.

                     Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/