Re: silent semantic changes with reiser4

From: Helge Hafting
Date: Sat Aug 28 2004 - 12:02:18 EST


On Fri, Aug 27, 2004 at 07:05:35PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 27 Aug 2004, Rik van Riel wrote:
> >
> > Thing is, there is no way to distinguish between what are
> > virtual files and what are actual streams hidden inside a
> > file. You don't know what should and shouldn't be backed
> > up...
>
> I think that lack of distinguishing poiwer is more serious for
> directories. The more I think I think about it, the more I wonder whether
> Solaris did things right - having a special operation to "cross the
> boundary".
>
> I suspect Solaris did it that way because it's a hell of a lot easier to
> do it like that, but regardless, it would solve the issue of real
> directories having both real children _and_ the "extra streams".

There are many ways of doing this. Several extra streams to a directory
that aren't ordinary files in the directory?

It seems to me that we can get a lot of nice functionality in a simpler way:
Instead of thinking about a number of streams attached to something
that is either an ordinary file or directory, just say that the only
change will be that a directory may have a _single_ file stream in
addition to being a plain directory.

The conceptual change is smaller. Still you achieve multiple
streams, the "main" stream in such a dir+file is the single stream
attached to the directory. All the "extra streams" are files inside the
(normal) directory.

* This way, the extra streams aren't "special" in any way and
should work fine with existing tools.
* Serving such a filesystem to clients that use multiple streams
will allow any number of streams per file for them
* Moving the directory+file thing will move both the directory and
the special stream, and all the extra streams follow because they're
ïpart of the directory as usualï.

If the VFS is to be extended in order to support file-as-directory (or
vice versa) then hopefully it can be done in a simple way.

Helge Hafting

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