Re: silent semantic changes with reiser4

[Jamie Lokier]

Christoph Hellwig wrote:
> > Unfortunately, the problem is that reiser4 is the only filesystem
> > which is _technically capable_ of implementing that abstraction in a
> > practical way, apparently.  (I'm not sure if this is really true.
> > reiser4's object model is not the same as paths and inodes, but the
> > impedance mismatch doesn't seem huge.)
> 
> Umm, no.  In fact every filesystem does this.  There's not too many
> objects with different namespace semantic: regular files and special
> files vs directories vs symlinks basically, but as soon as you go to the
> data patch you can have hundrets of different file_operations on a
> single filesystems (for special files).

Remember that reiser4 allows you to operate on little pieces of data,
glueing and rearranging them inside files (something like that).

No other filesystem has that capability, and it's a data model which
the fancy features (when they exist) will use.

You can map those pieces to underlying directories and files and
renames and unlinks, so that the fancy stuff works on other
filesystems, but it would be a useless model because those other
filesystems wouldn't be recognisably "ordinary" files any more.

For reiser4 to expose that model through a VFS interface, and the
fancy stuff to use it through the VFS interface, and for the fancy
stuff to work (even imperfectly) on other filesystems which don't
offer those operations, some kind of fall-back "store metadata and
fragment rearrangements in auxiliary files with special names" layer
would be requied.  That's a big job.

I think it's a good job to do (funding, anyone? :), and the right
place for that (imperfect but useful) fall-back layer is userspace
with perhaps minimal VFS support.  Another reason to put the fall-back
layer in userspace is that applications which depend on the fancy
stuff can still be portable to other OSes, working, but a bit
smoother, faster and more "integrated" on reiser4.

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