Re: reiser4 plugins

[Kyle Moffett <mrmacman_g4@mac.com>]

On Jun 27, 2005, at 17:19:21, David Masover wrote:
> > Precisely.  Come back when you have a good sturdy set of  
> > arguments.  See
> > the FUSE project (Also discussed in this thread), for better ideas  
> > on  how
> > to add strange filesystem semantics.
>
> If I didn't care about performance.  I will read up on how FUSE works,
> though, to see if there's anything in the _kernel_ code that would be
> useful.

A number of projects do their performance critical things in userspace,
including real-time audio and video editing.  The kernel is *NOT* for
performance-critical things, unless they cannot be done efficiently in
userspace.  It is for _security_critical_ and _stability_critical_  
things,
and even then, some of those are pushed to userspace as well.

> > NOTE:  Even the FUSE project,  which
> > is in _userspace_ (as opposed to the massive kernelspace mess of   
> > reiser4),
> > is taking a lot of flak for changing UNIX semantics, so I see no  
> > reason
> > why Reiser4 should be special.
>
> Right.  Kernel people hate change.  Got it.
>
> No, seriously, I have to respect the history involved, which is why  
> I'm
> not pretending to know more than I do.

There is a good reason to hate change (at least without thorough  
evidence
to back it up).  Even small changes can break things in subtle ways.   
Big
changes can tend to wreak kernel-global (and even userspace-global)  
havoc.

> > Ok, good.  That's one of the first issues.  A _lot_ of applications
> > would get themselves thoroughly confused at that '...' interface, not
> > to  mention a lot of sysadmins :-D.
>
> Not as much as you think.  Unless a lot of applications can't handle
> opening or saving files that have '...' in the pathname?

If those files are as special as you lead me to believe, even a simple
"tar -cjvf foo.tar.bz2 foo" would break horribly, because it would  
tar up
all sorts of strange special files that shouldn't be included.  Worse,
when I untar that archive on the filesystem, it will overwrite those  
files,
which probably should be overwritten even less than they should be  
stored
in an archive.

> The sysadmin problem doesn't worry me so much.

Personally, I know several sysadmins who, never having heard of Reiser4
but using it anyways, would get scared when all of the '...' directories
started showing up, thinking that some cracker had gotten a module  
loaded
in their kernel.  If you can, please avoid overloading existing  
semantics
in filesystems.  You can either claim that your filesystem is POSIXy,
(similar to ext3, xfs, etc), or you can claim that it's not  
compatible by
design (AFS, Coda) or you can claim that it's a completely virtualized
interface (procfs, sysfs, CKRM fs, etc) and doesn't care about POSIX in
any case.  Reiser4 definitely isn't the third, but neither is it  
either of
the first two, because it would break standard operations.

> Agreed.  I don't know enough about VFS to propose one, though.  I  
> think
> others are working on that, finally.

When the VFS work gets done, this discussion can move on, otherwise, we
are stuck at an impasse.

> Not too much, I hope.
>
> Although being able to use different keys on a per-file basis would be
> nice.  I'm not sure if that would work in the existing system.  Not to
> mention that keys would also be handlable with '...', if/when it  
> happens.

I think the '...' is just a bad idea in general, because it breaks tar
and such.  An interface like this might be simpler to design and use:

# mkdir /attr
# mount -t attrfs attrfs /attr

/attr/fd/$FD_NUM              == '...' directory for a filedescriptor
/attr/fs/$DEV_NUM/$INODE_NUM  == '...' directory for an inode

It would be usable from a shell with a simple "getattrpath" command
which returns "fs/$DEV_NUM/$INODE_NUM" by stat-ing any given path.

Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to  
make it so simple that there are obviously no deficiencies. And the  
other way is to make it so complicated that there are no obvious  
deficiencies.
 -- C.A.R. Hoare

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