Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

For one thing, can I access a Beagle search as a folder?

> BUT they haven't used the standard mechanisms available for implementing
> them, such for Beagle to work on Reiser4, there now needs to be logic
> added to Beagle to do so.

Well, ideally, I'd like to see people stop bickering, come up with
something better than sys_reiser4, add an emulation layer for xattrs and
mark them obsolete.

But I don't speak for Namesys.

> 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

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

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, back to reality.  file-as-directory probably won't happen, at least
not for awhile, so imagine more along the lines of my first example.

> how about encryption?

About the same, only now you have a key file that you write to in order
to unlock the decrypted files.

> ... and so-on.
> suddenly every user app out there needs to have specialized knowledge of
> each type of filesystem.

Not really.

More like, every app that cares to has generalized knowledge, if that.

> none of this is rocket-science.  its just plain common sense.

I could say the same of my stuff, but lots of people seem to disagree
with me, or at least fail to see it.  I guess I can say the same of your
comments.

>> It's a filesysem for gods sake. Hans and his team have worked hard to
>> minimize its impact and they are still willing to accept more
>> guidance,
>>
> i don't see any acceptance at this point.  simply lots of hot air that
> smells like marketing & PR.

They do keep asking for specifically what they need to do to put this
stuff in VFS.  Or am I wrong?

Or maybe it should be obvious to them?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQr5dtngHNmZLgCUhAQIBGxAAiLK6EyHnLRhEA+rUIDCwacM4K89wlE7X
+dcw3xv3Pc9tZZqVVAd7Y27whEzjmNOwfGkvPkzPk/ATQditnyt+7xHcuXpqORNU
j7zHc5zS8MGDRU8Re4MXTO6jCXDgtTwQHjcdg4i8KYWLMPT7LpO+DHY/mZyQEgpD
kZGE4WJePA+aNlHAzySW9u/atnwp5hSRvmfuF4zzN8ng5tf8SSMvbfoCyjYSue8l
N6jvcGnt+yItmbHVaij0IdHUw1/9/u6b3Q0Ut39NBk8fUKXJcASHmKtjwLTAoWW+
hiYVhLdZQGkWo2d6XdzdNY2OgE3kWVnLBqrOuTo7zCjMojvWIrEGE/x3Yh/E6Hs8
cAPVRebG5yUQBxJk1lcDeJOBozutIpCVyTzwBnKU1nz3KArqanU51oT++3cTjVha
1tBnaLS4RLcdy8UD1ewS+VHj61VSlcBjv2abCrYw4DC0anUFrYUSciNjx3tdYJRx
o7l/pEn7UYPpGaXgHyBdVDIRlRNdOoTRZp3aIY2Z2v6/jyi3TeufMUjGtpuQHl2k
BuYm7tV4l1Ec/QZLM+PbAyVU9qqlz9BuHlI1U7z1p3gYeAzz0guAeDHfi1l95sUn
l+bFCOfmXi3qRAxVZyidczqeOtGtCed3nIUH+1z+siuFzH3jecjzUpGWKcGxzVlc
jkUS+tlihfg=
=C4UP
-----END PGP SIGNATURE-----