reiser4 plugins

[Geneva-2]

Christoph,

Reiser4 users love the plugin concept, and all audiences which have
listened to a presentation on plugins have been quite positive about
it.  Many users think it is the best thing about reiser4.  Can you
articulate why you are opposed to plugins in more detail?  Perhaps you
are simply not as familiar with it as the audiences I have presented
to.  Perhaps persons on our mailing list can comment.....

In particular, what is wrong with having a plugin id associated with
every file, storing the pluginid on disk in permanent storage in the
stat data, and having that plugin id define the set of methods that
implement the vfs operations associated with a particular file, rather
than defining VFS methods only at filesystem granularity?

What is wrong with having an encryption plugin implemented in this
manner?  What is wrong with being able to have some files implemented
using a compression plugin, and others in the same filesystem not.

What is wrong with having one file in the FS use a write only plugin, in
which the encrypion key is changed with every append in a forward but
not backward computable manner, and in order to read a file you must
either have a key that is stored on another computer or be reading what
was written after the moment of cracking root?

What is wrong with having a set of critical data files use a CRC
checking file plugin?

What we have hurts no one but us.  I have never seen an audience for one
of my talks that thought it hurt us..... most audiences think it is
great.  

Let us tinker with our FS, and you tinker with yours, and so long as
what we do does not affect your FS, let the users choose.

In the end, somebody will write a new fs that steals the good ideas from
both of us, and obsoletes us both.  They can only do this though if we
are left to be both free to implement differing filesystem designs.

I do not tell you how to design XFS, why are you making my life unpleasant?

Christoph Hellwig wrote:

>Hans, we had this discussion before.  And the consensus was pretty simple:
>the disk structure plugins are your business and fine to keep.  The
>higher-level pluging that just add another useless abstraction below
>file_operation/inode_operation/etc.  are not.  keep the former and kill
>the latter and you're one step further.
>
>
>  
>

[Jeff Garzik]

Hans Reiser wrote:

> Christoph,
>
> Reiser4 users love the plugin concept, and all audiences which have
> listened to a presentation on plugins have been quite positive about
> it.  Many users think it is the best thing about reiser4.  Can you
> articulate why you are opposed to plugins in more detail?  Perhaps you
> are simply not as familiar with it as the audiences I have presented
> to.  Perhaps persons on our mailing list can comment.....
>
> In particular, what is wrong with having a plugin id associated with
> every file, storing the pluginid on disk in permanent storage in the
> stat data, and having that plugin id define the set of methods that
> implement the vfs operations associated with a particular file, rather
> than defining VFS methods only at filesystem granularity?

You're basically implementing another VFS layer inside of reiser4, which
is a big layering violation.

This sort of feature should -not- be done at the low-level filesystem level.

What happens if people decide plugins are a good idea, and they want
them in ext3?  We need massive surgery to extract the guts from reiser4.

        Jeff

[Andrew Morton-8]

Hans Reiser <reiser@...> wrote:

>
> What is wrong with having an encryption plugin implemented in this
>  manner?  What is wrong with being able to have some files implemented
>  using a compression plugin, and others in the same filesystem not.
>
>  What is wrong with having one file in the FS use a write only plugin, in
>  which the encrypion key is changed with every append in a forward but
>  not backward computable manner, and in order to read a file you must
>  either have a key that is stored on another computer or be reading what
>  was written after the moment of cracking root?
>
>  What is wrong with having a set of critical data files use a CRC
>  checking file plugin?

I think the concern here is that this is implemented at the wrong level.

In Linux, a filesystem is some dumb thing which implements
address_space_operations, filesystem_operations, etc.

Advanced features such as those which you describe are implemented on top
of the filesystem, not within it.  reiser4 turns it all upside down.

Now, some of the features which you envision are not amenable to
above-the-fs implementations.  But some will be, and that's where we should
implement those.

[Geneva-2]

Andi Kleen wrote:

> Christoph does a lot of reviewing
>
and he is notorious for making needed linux contributors go away and not
come back, and I won't say which famous person on this mailing list told
me that....

>and your child definitely
>is in serious need of that to be mergeable. I'm sure Christoph is able
>to review inpartially even when he is involved with other FS.
>  
>
As impartial as a puppy on PCP....

Christoph is aggressive about things he does not take the time to
understand or ask about first.  I hate that.   I wish he would go away
please.  He is not exactly an Ousterhout, Rob Pike, Granger, Mazieres,
Frans Kaashoek, etc.,  in his accomplishments, so why is he reviewing
other people's filesystems?  Reviews are great, how about finding
persons who have created filesystem innovations (and thus are less
likely to reject innovations without understanding them) to do them?

How about review by benchmark instead?

It works, it runs faster than the competition, users like it, we
addressed the core kernel patch complaints, it should go in and receive
the exposure that will result in lots of useful improvements and
suggestions.   It seems like we are getting an unusual review process.

I used a bunch of algorithms for which there was a consensus among those
consulted that the algorithms were a bad idea, only the fact that I paid
for the code to be written and required that it be done my way (ignoring
the "you just use me as a typewriter" remarks as best I could)  caused
the algorithms to get implemented at all, and the benchmarks then proved
the algorithms were a good idea.  V3 performance sucks in major part
because I listened to the consensus when I knew better.   I don't really
care for consensus on my FS anymore.   If you guys want to understand
what I am doing I am happy to talk about it extensively, but please
don't require that I groupthink.  I frankly think that with my
benchmarks, I should be allowed to tinker on my own.

Hans The Mad

[Kyle Moffett]

On Jun 21, 2005, at 22:47:13, Hans Reiser wrote:
> Andi Kleen wrote:
>> and your child definitely
>> is in serious need of that to be mergeable. I'm sure Christoph is  
>> able
>> to review inpartially even when he is involved with other FS.
> As impartial as a puppy on PCP....

So where else are you planning to get a competent reviewer who is fluent
in the internals of filesystems?  Good reviewers don't grow on trees,  
and
in order to be able to understand filesystem issues, one must generally
have worked with them before...  Besides, what good is insulting others
going to do?

> Christoph is aggressive about things he does not take the time to
> understand or ask about first.
[rant snipped]

 From my objective re-reading of his posts, I can see that he is  
critical
of things that are difficult to understand not just to be critical, but
to provoke additional thought over those portions of the code.  In many
cases this leads to better abstractions and simpler code than otherwise.

> How about review by benchmark instead?

/dev/sda is a great filesystem with awesome benchmarks, assuming one  
only
needs to store a single file.  Besides, benchmarks aren't the only thing
important about code.  If the interface consists of:

   void clear_current_filename(void);
   void add_char_to_current_filename(char x);
   void read_bytes_from_current_file(char *byte, unsigned long size);
   void write_bytes_to_current_file(const char *byte, unsigned long  
size);

then this is clearly not a good API, regardless of how well or poorly it
may perform.

> It works, it runs faster than the competition, users like it, we
> addressed the core kernel patch complaints, it should go in and  
> receive
> the exposure that will result in lots of useful improvements and
> suggestions.   It seems like we are getting an unusual review process.

If you look over other patches in -mm, you will see that your review
process is not unusual, especially given the number of concerns that  
other
developers have raised over Reiser4.

[irrelevant algorithm rant snipped]

> If you guys want to understand
> what I am doing I am happy to talk about it extensively, but please
> don't require that I groupthink.  I frankly think that with my
> benchmarks, I should be allowed to tinker on my own.

Yes, you can tinker on your own all you want.  Another project that has
taken that route is GrSecurity, which was alive and well last I checked.

If you don't like others criticisms, take up your marbles and go home,
just don't expect them to accept your work when you've not fixed it to
community standards.

Cheers,
Kyle Moffett

--
Somone asked my why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best  
answer:

"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't.  
That's why
I draw cartoons. It's my life."
-- Charles Shultz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[David Masover]

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

Jeff Garzik wrote:

> Hans Reiser wrote:
>
>> Christoph,
>>
>> Reiser4 users love the plugin concept, and all audiences which have
>> listened to a presentation on plugins have been quite positive about
>> it.  Many users think it is the best thing about reiser4.  Can you
>> articulate why you are opposed to plugins in more detail?  Perhaps you
>> are simply not as familiar with it as the audiences I have presented
>> to.  Perhaps persons on our mailing list can comment.....
>>
>> In particular, what is wrong with having a plugin id associated with
>> every file, storing the pluginid on disk in permanent storage in the
>> stat data, and having that plugin id define the set of methods that
>> implement the vfs operations associated with a particular file, rather
>> than defining VFS methods only at filesystem granularity?
>
>
> You're basically implementing another VFS layer inside of reiser4, which
> is a big layering violation.

There's been sloppy code in the kernel before.  I remember one bit in
particular which was commented "Fuck me gently with a chainsaw."  If I
remember correctly, this had all of the PCI ids and the names and
manufacturers of the corresponding devices -- in a data structure -- in
C source code.  It was something like one massive array definition, or
maybe it was a structure.  I don't remember exactly, but...

The point is, this was in the kernel for quite awhile, and it was so
ugly that someone would rather be fucked with a chainsaw.  If something
that bad can make it in the kernel and stay for awhile because it
worked, and no one wanted to replace it -- nowdays, that database is
kept in userland as some nice text format -- then I vote for putting
Reiser4 in the kernel now, and ironing the sloppiness ("violation") out
later.  It runs now.

> This sort of feature should -not- be done at the low-level filesystem
> level.

I agree there, too.  In fact, some people have suggested that all
"legacy" (read: non-reiser) filesystems should be implemented as Reiser4
plugins, effectively killing VFS.*

So, Reiser4 may eventually take over VFS and be the only Linux
filesystem, but if so, it will have to do it much more slowly.  Take the
good ideas -- things like plugins -- and make them at least look like
incremental updates to the current VFS, and make them available to all
filesystems.

Eventually, this would result in a full merge of Reiser and Linux, such
that the only thing left of "Reiser4" are a few plugins -- things like
storage plugins and maybe some more exotic things like fibration that I
don't really understand.

> What happens if people decide plugins are a good idea, and they want
> them in ext3?  We need massive surgery to extract the guts from reiser4.

And here is the crucial point.  Reiser4 is usable and useful NOW, not
after it has undergone massive surgery, and Namesys is bankrupt, and
users have given up and moved on to XFS.  But the massive surgery should
happen eventually, partly to make all filesystems better (see below),
and partly to make the transition easier and more palatable for those
who don't work for Namesys.





* Imagine ext3 as a storage-level plugin for reiser4.  You get one
benefit immediately -- lazy allocation.  Lazy allocation is nice both
for fragmentation and for busy systems writing and nuking a lot of
temporary files.  Imagine a file which is written and then deleted
before it hits disk -- it should never touch the disk, regardless of the
underlying storage layout.

Other benefits are subtler but inevitable.  Right now, it would be an
understatement to say that there's duplication of effort between ext3,
xfs, and reiser4.  And yet, I don't think there are many core design
decisions that influence my decision as to which I pick up.  I just want
it to be fast, stable, and have a stable on-disk format so I don't have
to reformat too often.  I honestly don't care about how XFS is
segmenting the disk, or Reiser4 packs really well, or ext3 can be read
as ext2 and flushes to disk every five seconds.  These are the kinds of
things which should be set to sane defaults, tunable for enterprise
users, but are not really enough to warrant completely separate code bases.

I would imagine that it wouldn't be too long after this before an
uber-fs rose, something which combined enough of the strong points of
all the existing Linux filesystems that no one would use anything else.
 But, Linux still needs support for FAT32, ISO9660, UDF, and all the
other filesystems which won't go away as easily as XFS and ext3, and it
would be nice if these could all share as much code as possible.


I don't know if storage plugins really work that way, but they should.

I think.  I don't work here.

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

iQIVAwUBQrjoNHgHNmZLgCUhAQIYYw/7BWZ0gVvy0ln5tRo405yUoRHJ/jVFBGyP
5pQ610ECMZORVWRO1qP/NXbvGZwDjEggM5iIeahsGqnBWzNGDsB6RslMUZAxzCYy
iAovi0881zoARf3dmhKrDgbGkvNLPTx+/ypa20oRcHLnyI+NAjerUxNuvGc79PJn
Ybm9JhX6tQsqGIKjZye9uNDHCifLqzA1gdxucPwWo9sz4ymzM9FgsMGvb+IxrU50
2a2G2K6AHcH+nkomEHw3xgY3PmUZUy0s2hQDSkJx6dCido7fGZwwykaSXm4IZs9s
xZqBxKx32G/LDnDV3W8gpj8ZisUE+58kefRbIjo4Ml6IzgXvQqpRjaQOuz8JoKDX
9KUV43tcZkPpK+neIYPQYpXCrdMQqB5+ISpbNKuz/Z/abkcVw1042sy0EKM+/VnD
n3Jr7PpSyk0lfCyADr+33qnqPQRFq02gQTohg9FheoMthhV01aaeGW5ExmTM/Wwa
6Dmv/qnn2oNImi+Ebz5u3Lbnz7lL3MVpRL4aoMmEOVUB3xhehnxesf//yacBmwj9
M/3KVae9epwX4K6yi8qQXzH4160IBFHpWUxBLc9LnOZlHQuZ+Fz3BIrbKQBvmaHT
7lrwi0Os6TmiBGMSFd6OUWHcYs4p97aMw30NG33fCL6e8X6oNVFwwnJXZpBPN1Mr
+lrsVAywKEI=
=rHdK
-----END PGP SIGNATURE-----

[Bedros Hanounik]

First of all, I'm HW engineer, and don't know much about implementation details of FS. I know some coding, I've coded for different levels from linux device drivers to GUI's, but I know a lot about integration between levels of hierarchy.

I generally agree with the idea that high level functionality such as compressing, encrypting, ...etc should not be implemented in the FS. But, the term "high-level" is a relative term and three years down the road, what we consider high-level now becomes low-level.

my suggestion is to keep everything as is. if Hans and the reiser4 guys want to implement high level stuff as plug-ins that's fine. If the VFS guys want to implement the same functionality in VFS on top of the system FS; they can do it too.

BUT PLEASE MAKE THE API COMPATIBLE!!!!

programmers on both sides should discuss the features and make sure the API is compatible.

in such a scenario, if I want to compress a directory called /mystuff/data on a reiser4 FS, I could call the VFS API to do so; The VFS finds that the system is reiser4 and compression is supported, so it passes the call to reiser4. On another hand, if the system is ext3 and it doens't support compression, VFS performs the task and passes the file to ext3.

My point is that  the effect of gravity is upon us, high level stuff will become low-level in a short time. Moreover, at the low level in FS and especially when done by FS guys, functions such as compression can be done more efficiently than in VFS space.

my  worries are that the waste of effort by implementing the same functionality in two levels in the hierarchy, and incompatible API can cause serious headache.

just my two cents.

-Bedros

On 6/21/05, David Masover <ninja@...> wrote:

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

Jeff Garzik wrote:

> Hans Reiser wrote:
>
>> Christoph,
>>
>> Reiser4 users love the plugin concept, and all audiences which have
>> listened to a presentation on plugins have been quite positive about
>> it.  Many users think it is the best thing about reiser4.  Can you
>> articulate why you are opposed to plugins in more detail?  Perhaps you
>> are simply not as familiar with it as the audiences I have presented
>> to.  Perhaps persons on our mailing list can comment.....
>>
>> In particular, what is wrong with having a plugin id associated with
>> every file, storing the pluginid on disk in permanent storage in the
>> stat data, and having that plugin id define the set of methods that
>> implement the vfs operations associated with a particular file, rather
>> than defining VFS methods only at filesystem granularity?
>
>
> You're basically implementing another VFS layer inside of reiser4, which
> is a big layering violation.

There's been sloppy code in the kernel before.  I remember one bit in
particular which was commented "Fuck me gently with a chainsaw."  If I
remember correctly, this had all of the PCI ids and the names and
manufacturers of the corresponding devices -- in a data structure -- in
C source code.  It was something like one massive array definition, or
maybe it was a structure.  I don't remember exactly, but...

The point is, this was in the kernel for quite awhile, and it was so
ugly that someone would rather be fucked with a chainsaw.  If something
that bad can make it in the kernel and stay for awhile because it
worked, and no one wanted to replace it -- nowdays, that database is
kept in userland as some nice text format -- then I vote for putting
Reiser4 in the kernel now, and ironing the sloppiness ("violation") out
later.  It runs now.

> This sort of feature should -not- be done at the low-level filesystem
> level.

I agree there, too.  In fact, some people have suggested that all
"legacy" (read: non-reiser) filesystems should be implemented as Reiser4
plugins, effectively killing VFS.*

So, Reiser4 may eventually take over VFS and be the only Linux
filesystem, but if so, it will have to do it much more slowly.  Take the
good ideas -- things like plugins -- and make them at least look like
incremental updates to the current VFS, and make them available to all
filesystems.

Eventually, this would result in a full merge of Reiser and Linux, such
that the only thing left of "Reiser4" are a few plugins -- things like
storage plugins and maybe some more exotic things like fibration that I
don't really understand.

> What happens if people decide plugins are a good idea, and they want
> them in ext3?  We need massive surgery to extract the guts from reiser4.

And here is the crucial point.  Reiser4 is usable and useful NOW, not
after it has undergone massive surgery, and Namesys is bankrupt, and
users have given up and moved on to XFS.  But the massive surgery should
happen eventually, partly to make all filesystems better (see below),
and partly to make the transition easier and more palatable for those
who don't work for Namesys.





* Imagine ext3 as a storage-level plugin for reiser4.  You get one
benefit immediately -- lazy allocation.  Lazy allocation is nice both
for fragmentation and for busy systems writing and nuking a lot of
temporary files.  Imagine a file which is written and then deleted
before it hits disk -- it should never touch the disk, regardless of the
underlying storage layout.

Other benefits are subtler but inevitable.  Right now, it would be an
understatement to say that there's duplication of effort between ext3,
xfs, and reiser4.  And yet, I don't think there are many core design
decisions that influence my decision as to which I pick up.  I just want
it to be fast, stable, and have a stable on-disk format so I don't have
to reformat too often.  I honestly don't care about how XFS is
segmenting the disk, or Reiser4 packs really well, or ext3 can be read
as ext2 and flushes to disk every five seconds.  These are the kinds of
things which should be set to sane defaults, tunable for enterprise
users, but are not really enough to warrant completely separate code bases.

I would imagine that it wouldn't be too long after this before an
uber-fs rose, something which combined enough of the strong points of
all the existing Linux filesystems that no one would use anything else.
But, Linux still needs support for FAT32, ISO9660, UDF, and all the
other filesystems which won't go away as easily as XFS and ext3, and it
would be nice if these could all share as much code as possible.


I don't know if storage plugins really work that way, but they should.

I think.  I don't work here.

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

iQIVAwUBQrjoNHgHNmZLgCUhAQIYYw/7BWZ0gVvy0ln5tRo405yUoRHJ/jVFBGyP
5pQ610ECMZORVWRO1qP/NXbvGZwDjEggM5iIeahsGqnBWzNGDsB6RslMUZAxzCYy
iAovi0881zoARf3dmhKrDgbGkvNLPTx+/ypa20oRcHLnyI+NAjerUxNuvGc79PJn
Ybm9JhX6tQsqGIKjZye9uNDHCifLqzA1gdxucPwWo9sz4ymzM9FgsMGvb+IxrU50
2a2G2K6AHcH+nkomEHw3xgY3PmUZUy0s2hQDSkJx6dCido7fGZwwykaSXm4IZs9s
xZqBxKx32G/LDnDV3W8gpj8ZisUE+58kefRbIjo4Ml6IzgXvQqpRjaQOuz8JoKDX
9KUV43tcZkPpK+neIYPQYpXCrdMQqB5+ISpbNKuz/Z/abkcVw1042sy0EKM+/VnD
n3Jr7PpSyk0lfCyADr+33qnqPQRFq02gQTohg9FheoMthhV01aaeGW5ExmTM/Wwa
6Dmv/qnn2oNImi+Ebz5u3Lbnz7lL3MVpRL4aoMmEOVUB3xhehnxesf//yacBmwj9
M/3KVae9epwX4K6yi8qQXzH4160IBFHpWUxBLc9LnOZlHQuZ+Fz3BIrbKQBvmaHT
7lrwi0Os6TmiBGMSFd6OUWHcYs4p97aMw30NG33fCL6e8X6oNVFwwnJXZpBPN1Mr
+lrsVAywKEI=
=rHdK
-----END PGP SIGNATURE-----

[Jeff Garzik]

David Masover wrote:

> There's been sloppy code in the kernel before.  I remember one bit in
> particular which was commented "Fuck me gently with a chainsaw."  If I
> remember correctly, this had all of the PCI ids and the names and
> manufacturers of the corresponding devices -- in a data structure -- in
> C source code.  It was something like one massive array definition, or
> maybe it was a structure.  I don't remember exactly, but...
>
> The point is, this was in the kernel for quite awhile, and it was so
> ugly that someone would rather be fucked with a chainsaw.  If something
> that bad can make it in the kernel and stay for awhile because it
> worked, and no one wanted to replace it -- nowdays, that database is
> kept in userland as some nice text format -- then I vote for putting
> Reiser4 in the kernel now, and ironing the sloppiness ("violation") out
> later.  It runs now.

Existence of ugly code is not an excuse to add more.

We have to maintain said ugly code for decades.  Maintainability is a
big deal when you deal with the timeframes we deal with.


> So, Reiser4 may eventually take over VFS and be the only Linux
> filesystem, but if so, it will have to do it much more slowly.  Take the
> good ideas -- things like plugins -- and make them at least look like
> incremental updates to the current VFS, and make them available to all
> filesystems.

This is how all Linux development is done.

The code evolves over time.

You have just described the path ReiserFS needs to take, in order to get
this stuff into the kernel, in fact.


> And here is the crucial point.  Reiser4 is usable and useful NOW, not
> after it has undergone massive surgery, and Namesys is bankrupt, and
> users have given up and moved on to XFS.  But the massive surgery should
> happen eventually, partly to make all filesystems better (see below),
> and partly to make the transition easier and more palatable for those
> who don't work for Namesys.

We care about technical merit, not some random company's financial
solvancy.  Reiser4 has layering violations, and doesn't work with the
current security layer.  Those are two biggies.

There is no entitlement to be merged in the upstream kernel.  If people
don't like how the Linux kernel is managed, they are free to maintain
their own fork.  If its better, people will use that instead.


> I would imagine that it wouldn't be too long after this before an
> uber-fs rose, something which combined enough of the strong points of
> all the existing Linux filesystems that no one would use anything else.
>  But, Linux still needs support for FAT32, ISO9660, UDF, and all the
> other filesystems which won't go away as easily as XFS and ext3, and it
> would be nice if these could all share as much code as possible.
>
>
> I don't know if storage plugins really work that way, but they should.

No, they shouldn't.


> I think.  I don't work here.

Obviously.

        Jeff

[Christoph Hellwig]

On Tue, Jun 21, 2005 at 06:07:58PM -0700, Hans Reiser wrote:
> Christoph,
>
> Reiser4 users love the plugin concept, and all audiences which have
> listened to a presentation on plugins have been quite positive about
> it.  Many users think it is the best thing about reiser4.  Can you
> articulate why you are opposed to plugins in more detail?  Perhaps you
> are simply not as familiar with it as the audiences I have presented
> to.  Perhaps persons on our mailing list can comment.....

You're duplicating the VFS infrastructure with your pluging system.

> In particular, what is wrong with having a plugin id associated with
> every file, storing the pluginid on disk in permanent storage in the
> stat data, and having that plugin id define the set of methods that
> implement the vfs operations associated with a particular file, rather
> than defining VFS methods only at filesystem granularity?

Hans, this only shows you didn't listen to be the last few times I
explained it to you.  There's nothing wrong with defining plug in IDs
associated with every file, and the linux file_operations, inode_operations,
etc.. are _not_ filesystem granularity but inode granularity (except in
reiser4 where you throw everything together just to add your own
de-multiplexer below).  So the only thing your plugin might need to is to
define it's own file or inode operations (in fact it might need a few
more things speaking from experience with kinda similar things, but it
certainly doesn't need to duplicate what's there)

> What is wrong with having an encryption plugin implemented in this
> manner?  What is wrong with being able to have some files implemented
> using a compression plugin, and others in the same filesystem not.

There's nothing wrong with that, although such things might be better
as a stackable filesystem.  Maybe they're not, and we'll find out once
people are prototyping these things and playing with them. But you don't
need your additional layer of abstraction for those anyway

> What is wrong with having one file in the FS use a write only plugin, in
> which the encrypion key is changed with every append in a forward but
> not backward computable manner, and in order to read a file you must
> either have a key that is stored on another computer or be reading what
> was written after the moment of cracking root?

Because root can read kernel memory this is completely useless :)
But if you want it as your private patch no one forbits you to do it,
just don't expect such security by obscurity to go into mainline.

> What we have hurts no one but us.  I have never seen an audience for one
> of my talks that thought it hurt us..... most audiences think it is
> great.  

most of your audience doesn't understand the fine points of filesystem
implementation.  they want your feature but don't care how it's implemented.
here it's the other way around - we don't care too much about what not so
important features we have but more about how sanely they're implemented.

> Let us tinker with our FS, and you tinker with yours, and so long as
> what we do does not affect your FS, let the users choose.

Now we're getting personal again, right?  My filesystems according to
MAINTAINERS are freevxfs and sysfs, but if you look at commit logs I've
done work on pretty much any filesystem in the tree, and often doing tree-wide
changes.  That's why I care about every new filesystem in the tree and not
a single one.

[Christoph Hellwig]

On Tue, Jun 21, 2005 at 11:25:24PM -0500, David Masover wrote:
> > You're basically implementing another VFS layer inside of reiser4, which
> > is a big layering violation.
>
> There's been sloppy code in the kernel before.  I remember one bit in
> particular which was commented "Fuck me gently with a chainsaw."  If I
> remember correctly, this had all of the PCI ids and the names and
> manufacturers of the corresponding devices -- in a data structure -- in
> C source code.  It was something like one massive array definition, or
> maybe it was a structure.  I don't remember exactly, but...

Every device driver has a big array of corresponing device ids as an
array in C code - oh my god we're doomed  .. not.


> I agree there, too.  In fact, some people have suggested that all
> "legacy" (read: non-reiser) filesystems should be implemented as Reiser4
> plugins, effectively killing VFS.*
>
> So, Reiser4 may eventually take over VFS and be the only Linux
> filesystem, but if so, it will have to do it much more slowly.  Take the
> good ideas -- things like plugins -- and make them at least look like
> incremental updates to the current VFS, and make them available to all
> filesystems.

And why exactly would we replace a stable, working abstraction with an unpoven
mess?

[David Masover]

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


Christoph Hellwig wrote:

> On Tue, Jun 21, 2005 at 11:25:24PM -0500, David Masover wrote:
>
>>>You're basically implementing another VFS layer inside of reiser4, which
>>>is a big layering violation.
>>
>>There's been sloppy code in the kernel before.  I remember one bit in
>>particular which was commented "Fuck me gently with a chainsaw."  If I
>>remember correctly, this had all of the PCI ids and the names and
>>manufacturers of the corresponding devices -- in a data structure -- in
>>C source code.  It was something like one massive array definition, or
>>maybe it was a structure.  I don't remember exactly, but...
>
>
> Every device driver has a big array of corresponing device ids as an
> array in C code - oh my god we're doomed  .. not.

I could throw the same sarcasm back at you.  We must be doomed because
Reiser does some stuff that VFS already does!  Or am I misunderstanding
the complaint?

>>I agree there, too.  In fact, some people have suggested that all
>>"legacy" (read: non-reiser) filesystems should be implemented as Reiser4
>>plugins, effectively killing VFS.*
>>
>>So, Reiser4 may eventually take over VFS and be the only Linux
>>filesystem, but if so, it will have to do it much more slowly.  Take the
>>good ideas -- things like plugins -- and make them at least look like
>>incremental updates to the current VFS, and make them available to all
>>filesystems.
>
>
> And why exactly would we replace a stable, working abstraction with an

unpoven
> mess?

How does it get proven if you won't give it a chance as a *separate*
unproven mess, with a big fat EXPERIMENTAL flag, for users to play with?

I know, it exists as a separate patch.  But it works now, and I think
the best way to "prove" it would be to package it with the kernel.

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

iQIVAwUBQrkXY3gHNmZLgCUhAQLQUw//ZFN1KS+2wS/yDMa+/oWXVemZ690sMCLx
ZlKGg82bnv2XxqMXQwuPG9V02oN/D+1bkPmZzr8rD/tm5WshxpAHroIhnp3ZVpRi
lbMwULFQ8Z8fcsY3+YUag4XAUYGK+tmIeZc47FJGL0avsRa3RFJsFm+Kb6E/fi2f
H4wda43rt2CJYD5GqCtMsqyxzHzPclKHq25betIcPWBOqvE5NzQbc2tFTo0n3KMb
vmyZc4B34kiKhrrW/7pZCxDpiGjoxr87F19Tk8IIltM9kAuSVLXgtY/T+2DA2vJE
2N/Offr1rZh9zSq8PGkGoI+K41AaY3CkeYGjUF2eiZd4qwE624/1jUSEg685Puse
091EuIMzdndJYM0H+OsaFtvH9Rc67Hv6yR7aucNF5j8sIam37y7Fl+MToRgJK1+E
7YSpm/Ld61RaPqbJ4mqv4f0fHLTa2SpbFI8vmA1ARuiA+/YtUz9jBjLrPtMo4ppj
VvNTVMmftUgRr1NlQ+MKJO4Kxt4kKQnt1OtUe2y4bjCqO7ldUvPWLKGhsY0EsS0k
9yymlBbhsjTFrY9CsyrThshyHe9ikBVSLY7i16W+KhjLF/FKaq9k93nHd4B5Shni
Km9zyd0DlCUr3Y20SpBDITCWtM0CL0YQzeEW0JJTxVpHIDjh6s65XcBfrlWwEUiw
j/GJZA5h+bw=
=fBov
-----END PGP SIGNATURE-----

[Geneva-2]

Jeff Garzik wrote:

>> after it has undergone massive surgery, and Namesys is bankrupt, and
>> users have given up and moved on to XFS.  But the massive surgery should
>> happen eventually, partly to make all filesystems better (see below),
>> and partly to make the transition easier and more palatable for those
>> who don't work for Namesys.
>
> And here is the crucial point.  Reiser4 is usable and useful NOW, not
>
> We care about technical merit, not some random company's financial
> solvancy.
>
>
>

Hmm,   that must be why Daniel Robbins, the creator of the distro with
the technically superior Gentoo approach, is still with us, yes?

If you cared about technical merit, you would discuss benchmarks, yes?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[David Masover]

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

Jeff Garzik wrote:

> David Masover wrote:
>
>> There's been sloppy code in the kernel before.  I remember one bit in
>> particular which was commented "Fuck me gently with a chainsaw."  If I
>> remember correctly, this had all of the PCI ids and the names and
>> manufacturers of the corresponding devices -- in a data structure -- in
>> C source code.  It was something like one massive array definition, or
>> maybe it was a structure.  I don't remember exactly, but...
>>
>> The point is, this was in the kernel for quite awhile, and it was so
>> ugly that someone would rather be fucked with a chainsaw.  If something
>> that bad can make it in the kernel and stay for awhile because it
>> worked, and no one wanted to replace it -- nowdays, that database is
>> kept in userland as some nice text format -- then I vote for putting
>> Reiser4 in the kernel now, and ironing the sloppiness ("violation") out
>> later.  It runs now.
>
>
> Existence of ugly code is not an excuse to add more.

Maybe not, but I'm making a point.  I'm sure that, at the time, people
wanted something that ran.  They wanted lspci to work.  It was generally
assumed that it would be cleaned up later, and it was.  Too much later,
but it happened, eventually.

I've been reading a bit of history, and the reason Linux got so popular
in the first place was the tendency to include stuff that worked and
provided a feature people wanted, even if it was ugly.  The philosophy
would be:  choose a good implementation over an ugly one, but choose an
ugly one over nothing at all.

> We have to maintain said ugly code for decades.  Maintainability is a
> big deal when you deal with the timeframes we deal with.

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.

>> So, Reiser4 may eventually take over VFS and be the only Linux
>> filesystem, but if so, it will have to do it much more slowly.  Take the
>> good ideas -- things like plugins -- and make them at least look like
>> incremental updates to the current VFS, and make them available to all
>> filesystems.
>
>
> This is how all Linux development is done.
>
> The code evolves over time.
>
> You have just described the path ReiserFS needs to take, in order to get
> this stuff into the kernel, in fact.

This is the path it needs to take, long term, for the sanity of
everyone.  But I don't think it can get there without being included,
short term.  People will stomp all over any attempts to change the VFS
as "unproven" and "unneccesary".  Do you think it will be any easier to
get this stuff into the kernel that way?

Better, I think, to drop it in, as-is, and move stuff incrementally from
the FS to the VFS.  That way, there's at least something intermediate
for people to use, test, and hammer/beat down, and for maintainers to
get more comfortable with the idea and the logistics of this beast in
their kernel.

>> And here is the crucial point.  Reiser4 is usable and useful NOW, not
>> after it has undergone massive surgery, and Namesys is bankrupt, and
>> users have given up and moved on to XFS.  But the massive surgery should
>> happen eventually, partly to make all filesystems better (see below),
>> and partly to make the transition easier and more palatable for those
>> who don't work for Namesys.
>
>
> We care about technical merit, not some random company's financial
> solvancy.  Reiser4 has layering violations, and doesn't work with the
> current security layer.  Those are two biggies.

Ah, so you mean to say, you care about how well something fits the
current model.  That has little to do with technical merit.

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

iQIVAwUBQrkqoHgHNmZLgCUhAQIKixAAnTJTJJpuCLatFp8syccjNnE7WdHlO/zx
G1bWuSthCnb7uaVb8buDeAlpArzttoguKKum0NE0khz/FjKw4YUXH4AEsVYGlZaO
nBYpw0MVyypNP+hZhEuo1T826frEOb6Z40Y1WZCpYwAZCs9EQQm7TeYSMjhD17Ew
PehYwUFUmnv1S7CpYNQvuboKh/1wuUQb6R2thjuCGJVkif8Mn2U20Fhk1/HIgnIr
OHoCD8ZgwoqBDPKQ6V26dUX+ZHzQVJX1j/IgLnnitJ9E4quIHNs33lq4S99DWta6
uDS4hkHgFMRemh37sA0FUMeitFsrwNb2b2f0o/X8MpDJmwbdrdg9kxvwfHqqgaz+
Enj0rBXO8E+5a4STTk4L2LaSR2+knSEFdj53MYYq4ABL07hEbJp2cNFKh5AFXvg0
wg5WoHt4HhhOeuftIG9Twv5tHIC5qoM57ae9yZzj783G9ZnXy0xBefUmH+pWVQsp
H1IpKIR4a0l8gV1AkJa6BUyAyzDDObFzmqcZ61W15Y2relD9Ow2qzVqMxroB78uJ
O+on741BecGtohB5xdfth9rwDY6JPkDug3C6zHzxSAkGGEnWIn6O8CzcGrGqS0Ta
EmB4LGw/fZqGcEYOOErqMC6GuImv2JbjtBOx8nAxM2OhGXFoDiD9FQaDaxWw9zjj
ROODOhm0aTA=
=ivqd
-----END PGP SIGNATURE-----

[Stefan Smietanowski]

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

Hi David

> And here is the crucial point.  Reiser4 is usable and useful NOW, not
> after it has undergone massive surgery, and Namesys is bankrupt, and
> users have given up and moved on to XFS.  But the massive surgery should
> happen eventually, partly to make all filesystems better (see below),
> and partly to make the transition easier and more palatable for those
> who don't work for Namesys.

Sometimes someone comes with "I have this code NOW and if we just merge
it I'll fix it up properly". It's rejected, stating "come back when
you've fixed it up".

We don't even have that here. We have "I have this code NOW and when
it's merged I have no intention of fixing it up properly".

In my eyes I'd rather take the first one than the second, there at least
there's the INTENTION of fixing it up.

Oh and btw, I'm not pro- or against- reiserfs in any way. I haven't
tried reiserfs4 but I hear it's good so don't take this is a statement
of my like or dislike of it, I'm just stating something worth thinking
about.

// Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFCuTXZBrn2kJu9P78RAi0JAJwIp6uyAd3AL4mgSBMAH59h7CrklQCfRW+V
8ZlZqxHwnpqpHa8OURtUEuw=
=OD/E
-----END PGP SIGNATURE-----

[Rik van Riel]

On Tue, 21 Jun 2005, David Masover wrote:

> The point is, this was in the kernel for quite awhile, and it was so
> ugly that someone would rather be fucked with a chainsaw.  If something
> that bad can make it in the kernel and stay for awhile because it
> worked, and no one wanted to replace it

I would like to think we could learn from the mistakes
made in the past, instead of repeating them.

Ugly code often is so ugly people don't *want* to fix
it, so merging ugly code is often a big mistake.

--
The Theory of Escalating Commitment: "The cost of continuing mistakes is
borne by others, while the cost of admitting mistakes is borne by yourself."
  -- Joseph Stiglitz, Nobel Laureate in Economics

[Alexander Zarochentsev]

On Wednesday 22 June 2005 05:14, Jeff Garzik wrote:

> Hans Reiser wrote:
> > Christoph,
> >
> > Reiser4 users love the plugin concept, and all audiences which have
> > listened to a presentation on plugins have been quite positive about
> > it.  Many users think it is the best thing about reiser4.  Can you
> > articulate why you are opposed to plugins in more detail?  Perhaps you
> > are simply not as familiar with it as the audiences I have presented
> > to.  Perhaps persons on our mailing list can comment.....
> >
> > In particular, what is wrong with having a plugin id associated with
> > every file, storing the pluginid on disk in permanent storage in the
> > stat data, and having that plugin id define the set of methods that
> > implement the vfs operations associated with a particular file, rather
> > than defining VFS methods only at filesystem granularity?
>
> You're basically implementing another VFS layer inside of reiser4, which
> is a big layering violation.

Reiser4 suggests a bit more file types than VFS is aware of. I don't even
think VFS should be.  It is enough that VFS allows each inode/file/dentry  to
behave own way.  IIRC VFS object's ->foo_ops is for that.  

Reiser plugins are for the same.  Would you agree with reiser4 plugin design
if the plugins will not dispatch VFS object methods calls by themselves but
set ->foo_ops fileds instead?  I guess you don't like to have the two
dispatching systems at the same level.

> This sort of feature should -not- be done at the low-level filesystem
> level.
>
> What happens if people decide plugins are a good idea, and they want
> them in ext3?  We need massive surgery to extract the guts from reiser4.if
>
> Jeff

Thanks,
Alex

[Nikita Danilov]

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.

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.

Nikita.

[Christoph Hellwig]

On Wed, Jun 22, 2005 at 06:24:32PM +0400, Alexander Zarochentsev wrote:
> Reiser plugins are for the same.  Would you agree with reiser4 plugin design
> if the plugins will not dispatch VFS object methods calls by themselves but
> set ->foo_ops fileds instead?  I guess you don't like to have the two
> dispatching systems at the same level.

That is exactly the point I want to make.  I haven't looked at the design
in detail for a long time, but schemes to allow different object to have
different operation vectors is a good idea.  We already have that to
varying degrees in all filesystems, and making that more formal is a good
thing.  

[Christophe Saout]

Am Dienstag, den 21.06.2005, 18:18 -0700 schrieb Andrew Morton:

> > What is wrong with having an encryption plugin implemented in this
> >  manner?  What is wrong with being able to have some files implemented
> >  using a compression plugin, and others in the same filesystem not.
> >
> >  What is wrong with having one file in the FS use a write only plugin, in
> >  which the encrypion key is changed with every append in a forward but
> >  not backward computable manner, and in order to read a file you must
> >  either have a key that is stored on another computer or be reading what
> >  was written after the moment of cracking root?
> >
> >  What is wrong with having a set of critical data files use a CRC
> >  checking file plugin?
>
> I think the concern here is that this is implemented at the wrong level.
>
> In Linux, a filesystem is some dumb thing which implements
> address_space_operations, filesystem_operations, etc.
>
> Advanced features such as those which you describe are implemented on top
> of the filesystem, not within it.  reiser4 turns it all upside down.
>
> Now, some of the features which you envision are not amenable to
> above-the-fs implementations.  But some will be, and that's where we should
> implement those.

Yes, but that would be difficult, probably worse. The name "plugins" is
perhaps a bit misleading. These plugins are most of the time some sort
client to the reiser4 on-disk database structure. The core code is does
on-disk tree handling, journalling and these things. The plugins in turn
glue this core database system to the rest of the system in order to
make a filesystem of it. The "file plugin" tells the database how to
store files.

A compression plugins is more tricky. Files should be randomly
accessible and if you write in the middle of the file the compressed
block might change in size. For reiser4 this is not a problem since it
just tells the underlying database "give me some room for 1234 bytes and
insert it in the tree instead of the other block". The reiser4 core has
totally different semantics than the VFS layer and I don't see how these
things could be handled elsewhere in this simple way.

The reiser4 core is more some sort of library that abstracts a block
device and provides some sort of database API (which is highly optimized
for filesystem purposes). The actual filesystem is then another layer on
top of this. You could actually implement lots of different filesystems
on top of that database core.

The actual layer is a bit different though. The database core itself
registers with the Linux VFS and then passes the calls down to one of
the plugins which then calls back into the reiser4 core to do the actual
database modification. I think this was the point that Christoph was
criticizing the most.

Currently it looks like this:

             ,--------------.       ,--------------.
VFS -------> |              | ----> |              |
             | /fs/reiser4/ |       | .../plugins/ |
blockdev <-- |              | <---> |              |
             `--------------'       `--------------'

So the reiser4 code is introducing another abstraction of the Linux VFS
layer instead of letting the plugins define the Linux VFS ops directly.
Which would look like this:

                                    ,--------------.
VFS ------------------------------> |              |
             ,--------------,       | .../plugins/ |
blockdev <-- | /fs/reiser4/ | <---> |              |
             `--------------'       `--------------'

Which probably would be okay for most of the time except for some
details (which could probably be solved otherwise).

Actually the flow is not always this simple, usually the path goes back
and forth multiple time between the core and the plugins.

One of the features Hans is using is that there can be different kinds
of files. The on-disk structure tells the core which of the plugins is
responsible for the "database object" found on the disk. It could be a
directory or a "stat data" (inode) or a file. The file itself could be
handled by different plugins like one that stores the data directly or
one that compresses it.

reiser4 is different than other filesystems in that it uses a lot more
abstraction levels. The database aspect and the semantic aspect of a
traditional filesystems are strongly separated.

To understand the code probably means a lot of work because it is a bit
different. Some of the layering concerns may be right, other probably
not.

The plugins that add additional VFS semantics (that are currently
disable) should most definitely not be implemented only inside the
filesystem. I think Hans did this because it would have been a lot more
work doing this at the proper layer (which means talking to people and a
lot of politics...).

The last time I looked at the code is a while ago, so if I'm wrong on
something, please don't shoot me. The only thing I can say is that
reiser4 has very stable for me (though I've gone back to reiser3 for
most of my filesystems because I wanted acl/xattr).

So here's my advice: Instead of insulting each other or doing pure
marketing talk, please try to address each detail and explain why
something has been done and if it's good or bad and if it should be
changed and how.

[Artem Bityutskiy-3]

Christophe Saout wrote:
> The plugins that add additional VFS semantics (that are currently
> disable) should most definitely not be implemented only inside the
> filesystem. I think Hans did this because it would have been a lot more
> work doing this at the proper layer (which means talking to people and a
> lot of politics...).
I would even do s/should most definitely not/must not/

More filesystems in future may want to use these semantics. There are
cases when one can't use Reiser4 to implement them, but instead, need to
implement another file system with the same semantics.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.