Re: reiser4 plugins

Timothy Webster
2005-06-24T09:38:58Z

--- Lincoln Dale <ltd@cisco.com> wrote:
snip

>
> Nikita basically said as much in Message-ID:
> <17081.30107.751071.983835@gargle.gargle.HOWL>
> earlier in this thread:
> "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.
>
> 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."

What reiserfs4 brings is file based plugins. Which is
extremely useful and powerful. I don't want to see
this go away.

I think it is the task of the linux community to
generalize the vfs layer and not lock out reiserfs4
until that is done. reiserfs4 wants to keep a plugin
id for each and every file. An additional filesystem
layer is the traditional solution to achieve advanced
features, but not an optimal solution in my opinion.
Yes gnome, kde and perhaps cifs do it. But if instead
they used file plugins a lot more could be shared.

Blush, I am not a file system expert

-Tim

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around