Re: silent semantic changes with reiser4

[Jan Harkes]

I trimmed/adjusted the CC list somewhat in the hope of getting a more
productive discussion going.

On Thu, Aug 26, 2004 at 09:48:04AM -0700, Linus Torvalds wrote:
> On Thu, 26 Aug 2004, Jan Harkes wrote:
> > 
> > (btw. the same could be implemented completely in userspace, for
> > instance in glibc. Whenever an open call gets an EISDIR error, simply
> > retry the open, but this time with /_contents appended).
> 
> Yes, and no - just to make it obvious before people jump on this, a lot of 
> things can be prototyped in user space with things like this, but once you 
> have to deal with races and mixed tool environments, user space suddenly 
> doesn't work so well any more.

Agreed.

> The same goes for something like a "container file". Whether you see it as
> "dir-as-file" or "file-as-dir" (and I agree with Jan that the two are
> totally equivalent), the point of having the capability in the kernel is

Only to some point. I was mostly trying to make the point that similar
functionality is already achievable within the current VFS framework.

However, files and directories still have some semantical differences,
and these are probably the points that we would have to address to get
Hans's efforts work well in cooperation with the Linux VFS.

We cannot atomically unlink a dir-as-file, but can unlink a file-as-dir.
In this case, the dcache seems to have no problems unlinking/unhashing a
non-empty directory, so I'm assuming that the unlink problem is mostly
enforced to avoid unreachable, but still allocated files in a file
system. (I'm sure that Viro can probably come up with other reasons why
unlinking a non-empty directory can be evil).

Also, we cannot create hardlinks to a directory (-as-file), but I guess
reiserfs4 allows hardlinks to files (-as-directory). Luckily as far as
hardlinked directories are concerned the file-as-dir implementation
should be a relatively benign subset. I assume that we are not allowed
to rename or link arbitrary objects from the regular fs into it, Coda
returns EXDEV in such situations. As a result there will be no cycles
and this simple premise should get rid of at least a couple of the
possible deadlock scenarios that I've seen mentioned.

Jan

-
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/