Re: reiser4 plugins

[Perry Kundert <perry.kundert@gmail.com>]

On 6/24/05, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> On Fri, 24 Jun 2005 11:13:45 MDT, Perry Kundert said:
> 
> >     In general, isn't it better to first include modules providing
> > divergent but possibly interesting functionality (such as Reiser4) as
> > an "optional" or "experimental" component, and then slowly re-factor
> > desirable functionality into higher level facilities like the VFS?
> 
> The problem arises when the facility is something that is demonstrably
> borked when done in an optional way in one filesystem, and really needs
> to be done at the VFS level if it is to be done at all.

    OK, fair enough.  The file-as-directory stuff, which introduces
VFS-incompatible issues, was turned off.  It requires VFS changes.

    The remaining plugin architecture, as far as I understand, deals
in the on-disk structure of the FS -- just like journals.  Encryption,
Compression, and the like.

    So, what you are saying, is -- so long as the "plugins" do stuff
that deals in how reiser4 slings bits back and forth to the disk,
you're OK, right?

> 
> >    I ask you -- if everyone in kernel-land is so convinced that you
> > should always select varying on-disk formats via the VFS, then *why*
> > hasn't ext2/ext3 been merged into a single filesystem?
> 
> Because the formats, although similar enough to be mostly compatible, are
> still different enough that merging them is difficult.

    So, what you are saying is: if reiser4 wants to provide
variability in on-disk format, so long as it implements it using
*multiple different filesystems* (eg reiser4-cryptcompress,
reiser4-whatever) -- just like ext2 vs. ext3 -- then you are OK with
it?  But, if they are implemented as "plugins", so that the ONE
reiser4 filesystem can modulate its behaviour based on what the
on-disk format says, that you are NOT OK with it?

    And this makes sense, why?

>                                                                         There's some very
> subtle second-order effects, where the ext3 driver can do things in different
> orders or with different algorithms because it has a journal, when the ext2
> code has to do things in a specific way because it has to *always* have things
> in a consistent enough state that fsck.ext2 can clean things up.  So you end
> up with code that looks like:
> ...

    Don't get me wrong -- I'm not saying that ext2 and ext3 shouldn't
be separate file systems.  However, if they were designed from the
start so that the ONE (say) ext23 filesystem could look at its on-disk
format, notice that the data specified the "journal" plugin, and
implement the correct behaviour -- that this would be "bad"?

    Because I can envision an ext23 filesystem that is just like
reiser4, that does exactly that -- implements its variable behaviour
via a "journal" plugin.

    So, if it did so, would you be OK with it?  As long as it wasn't
called reiser4?

    I really don't mean to sound sarcastic -- it just sounds like
there are "other" issues at work here -- like "Hans is a Butt-Head, so
I want to reject reiser4's plugin design for modulating its behviour,
no matter what".

> >                                                         Surely the
> > "journalling" plugin of this filesystem is a prime candidate for
> > selection via the VFS?
> 
> To be doing "journalling" at the VFS level implies that a journal is something
> that makes sense at the VFS level - that it's basically filesystem independent,
> which is most certainly *not* true - the notations an XFS journal needs to make
> to indicate which blocks were just removed from the free-block structure are
> quite different from what ext3 needs to record.

    Sort of like crypt/compress, etc. -- each filesystem may or may
not do this, but it just doesn't matter to the VFS -- by the time data
hits the VFS it isn't encrypted or compressed.  So, why not let the FS
say "hey, I happen to see that the on-disk format says it uses
cryptcompress -- I'll dispatch the right methods from this aptly-named
"plugin"...


> 
> Note that journalling is neither an attribute of the actual data, or of
> the user-visible metadata (inode contents, etc).   The only things that
> care about the journalling format/etc are the filesystem driver, the mount
> command, and the mkfs/fsck commands.   As such, it's a file system issue,
> not a VFS issue.
> 
> For a good example of why this is so, go back and read the recent discussion
> of what happens to flash memory filesystems mounted with 'sync' - this was
> a case of the VFS doing "journalling by flushing" without consulting the
> low-level drivers....
> 
> 
> 

    OK, so far it seems like we are actually agreeing -- the stuff
that gets done via reiser4 "plugins" actually doesn't have anything to
do with the VFS, and it shouldn't be there.  So long as reiser4
presents a VFS-sensible, VFS-consistent heirarchy of stuff that "looks
like" files and directories to the VFS, then we're OK with it?

    Whether reiser4 uses "plugins", or ESP, or whatever to decide what
behaviour it implements in order to produce this VFS-consistent
interface, then that's OK, right?

-- 
    -pjk