Re: reiser4 plugins

[Nikita Danilov <nikita@clusterfs.com>]

Vladimir Saveliev writes:
 > Hello
 > 
 > On Wed, 2005-06-22 at 18:28, Nikita Danilov wrote:
 > > David Masover writes:
 > > 
 > > [...]
 > > 
 > >  > 
 > >  > Maintainability is like optimization.  The maintainability of a
 > >  > non-working program is irrelevant.  You'd be right if we already had
 > >  > plugins-in-the-VFS.  We don't.  The most maintainable solution for
 > >  > plugins-in-the-FS that actually exists is Reiser4, exactly as it is now
 > >  > - -- because it is the _only_ one that actually exists right now.
 > > 
 > > But it is not so. There _are_ plugins-in-the-VFS. VFS operates on opaque
 > > objects (inodes, dentries, file system types) through interfaces:
 > > {inode,address_space,dentry,sb,etc.}_operations. Every file system
 > > back-end if free to implement whatever number of these interfaces. And
 > > the do this already: check the sources; even ext2 does this: e.g.,
 > > ext2_fast_symlink_inode_operations and ext2_symlink_inode_operations.
 > > 
 > 
 > imho, this is something different. Ext2 decides itself how to manage a
 > symlink depending on length of string the symlink is to store.
 > Reiser4 plugins are to allow a user to define himself which operations
 > file is to be managed with.

I fail to see this as an important distinction:

 - ext2    decides what "plugin" to use based on parameters supplied to
 the file creation system call;

 - reiser4 decides what "plugin" to use based on parameters supplied to
 the file creation system call.

 > 
 > > This is exactly what upper level reiser4 plugins are for.
 > 
 > > I guess that one of Christoph Hellwig's complaints is that reiser4
 > > introduces another layer of abstraction to implement something that
 > > already exists.
 > > 
 > 
 > I do not think that it exists already.
 > You can have standart type of files and that is all.
 > 
 > Linux filesystem is not supposed to provide anything but plain
 > regular/directory/symlinks/sockets/block device/char device/fifo files.

If you are talking about S_IFMT bits they are just a relic to keep user
level happy (yes, VFS does few S_ISFOO checks here and there, but they
all can be replaced with checks for appropriate operations being
non-NULL). Nothing prevents file system from rolling forward whatever
exotic objects it wants.

 > 
 > Existing file API does not allow create anything but that.
 > Merging reiser4 with object plugins would make it necessary to modify
 > VFS layer so that files of arbitrary types could be created.
 > 

This is important, but it doesn't depend on whether file system has
additional layer if indirection below VFS operations. If file system
wants to support extended object types, additional parameters have to be
somehow communicated from the user level during object creation. But:

 - this is necessary even if file system has no "plugins" below VFS
 operations;

 - this doesn't necessary means changing VFS. For example, these
 parameters can be set on parent directory (this is how ACLs were
 integrated into POSIX).

 >

Nikita.