Re: reiser4 plugins

[Valdis.Kletnieks@vt.edu]

On Sun, 26 Jun 2005 02:48:06 CDT, David Masover said:

> Lincoln Dale wrote:

> > this is the WHOLE point of standardization .. i don't think its that
> > Reiser4's EAs offer any more or less capabilities than standard EAs -
> 
> They do.  Reiser4's EAs can look like any other object -- files,
> folders, symlinks, whatever.  This is important, especially for
> transparency.

No, you want them to look like the same objects that {get|set}xattr() manage
currently.  You don't want programs to have to guess what an EA looks like
this week, with this user's combination of plugins that's different from
everybody else's.

> > lets take this a step further.  what about compression?  do we accept
> > that each filesystem can implement its own proprietary compression via
> > its own API - and now we need individual user-space tools to understand
> 
> No, that's the beauty of these "EAs" in Reiser4.  The API is standard
> write(2) commands.  sys_reiser4 supposedly implements an interface to
> make this scale better, but otherwise have the same semantics.  And who
> said anything about proprietary compression?  I think we were planning
> on the kernel's zlib, though we might have been planning to make it a
> bit more seekable...
> 
> > each of these APIs?
> 
> So, the API becomes something like:
> 
> cat crypto/inflated/foo		# transparently decompressed
> cat crypto/raw/foo.gz		# raw, gzip-compressed

And 'cat crypto/raw/foo' or 'crypto/inflated/foo.gz' gets you what, exactly?

Now throw some .bz2 and .zip files into the mix... ;)

> Another possibility, if you like file-as-a-directory:
> 
> cat foo.gz			# raw
> cat foo.gz/inflated		# decompressed
> 
> One could easily imagine things like these two potentially equivalent
> commands:
> 
> cp foo bar.zip/
> zip bar foo

Unless of course the user had done 'mkdir sorted.by.city.zip' to make
a directory of files containing data sorted by USPS Zip code.

And what happens if the user has a file 'bar' that's not a ZIP file,
and a directory 'bar.zip' isn't a view into 'bar'?

Most of the time, if I have a file 'linux-2.6.12.tar.bz2' and a
directory 'linux-2.6.12', what is under the directory is *NOT* the same
data as what's in the .bz2 - I've done 'make oldconfig' and a few builds
and some variable amount of patching, usually with rejects, and I *don't*
want that .bz2 being updated during all this (hint - what's my next command
after 'rm -rf linux-2.6.12' likely to be, and why, and  what expectations
do I have when I do it?)

You want to think this sort of thing through *really* thoroughly, because
there's a *lot* of things, both users and programs, that have expectations
about The Way Things Work.

> The whole point is to have less userland tools, not more.  I'm not
> saying we move zip into the kernel, just that the user now has one less
> command to remember.

But now instead of having to remember the one meme "I can manage any
compressed-archive format that's stored in a file, and put other files in it,
and all I need is the appropriate userspace tool", they have to remember "the
cp trick works for .zip and .tar, but I'll get a "not a directory" error if I
try it with a .hqx file, and that other file format may or may not work,
because I can't remember if this kernel has a working out-of-tree module for
this kernel...."

Attachment: pgpbNcr6zzLJM.pgp
Description: PGP signature