Re: silent semantic changes with reiser4

Linus Torvalds
2004-08-29T22:37:28Z

[ Linux-kernel cc'd, because I don't think the question is stupid, and I
can't even fully answer the kNFSd thing other than point to it as a
problem. ]

On Mon, 30 Aug 2004, Grzegorz Kulewski wrote:
>
> Sorry if my qestion is stupid, but why can't we deal with (hard)links to
> directories in (nearly) same way we deal with bind mounts (= making
> exactly one object representing target and only referencing to it)?

On a VFS level we could, these days, I think. But realize that bind mounts
and the vfsmounts are pretty recent things.

We don't have any filesystems that support the notion, though, and we
don't have any interfaces for the filesystem to tell us about it right
now. The VFS layer could try to figure it out on its own from aliasing
information, so the latter may be a non-issue, but the former is why
nobody does it.

And even if Linux _these days_ could handle hardlinked directories, the
fact is that they would cause slightly more memory usage (due to the
vfsmounts), and that nobody else can handle such filesystems - including
older versions of Linux. So nobody would likely use the feature (not to
mention that nobody is even really asking for it ;).

And the lack of filesystem support is not theoretical. It's not easy to
just retrofit directory hardlinks on a UNIX filesystem. The ".." entry
actually exists on _disk_ on traditional unix filesystems, and with
hardlinks on directories, that's a real problem. A hardlinked directory
has multiple parents.

Also, while the VFS layer no longer cares (to it, ".." is purely virtual,
and it never uses it), the NFS export routines still do actually want to
get the on-disk parent. A filesystem that can't do that may be unable to
be exported with full semantics (ie you might get ESTALE errors after
server reboots, although you'd have to ask somebody with more kNFSd
knowledge than me on exactly why that is the case ;)

Linus