Vladimir V. Saveliev <[email protected]> wrote:
> On Tue, 2006-08-01 at 17:32 +0200, Łukasz Mierzwa wrote:
> > Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds <[email protected]>
> > napisał:
> > > In other words, if a filesystem wants to do something fancy, it needs to
> > > do so WITH THE VFS LAYER, not as some plugin architecture of its own. We
> > > already have exactly the plugin interface we need, and it literally _is_
> > > the VFS interfaces - you can plug in your own filesystems with
> > > "register_filesystem()", which in turn indirectly allows you to plug in
> > > your per-file and per-directory operations for things like lookup etc.
> > What fancy (beside cryptocompress) does reiser4 do now?
>
> it is supposed to provide an ability to easy modify filesystem behaviour
> in various aspects without breaking compatibility.
If it just modifies /behaviour/ it can't really do much. And what can be
done here is more the job of the scheduler, not of the filesystem. Keep your
hands off it!
If it somehow modifies /on disk format/, it (by *definition*) isn't
compatible. Ditto.
> > Can someone point me to a list of things that are required by kernel
> > mainteiners to merge reiser4 into vanilla?
>
> list of features reiser4 does not have now:
> O_DIRECT support - we are working on it now
> various block size support
Is this required?
> quota support
> xattrs and acls
Without those, it is next to useless anyway.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Dnia Wed, 02 Aug 2006 20:45:07 +0200, Horst H. von Brand
<[email protected]> napisał:
> Vladimir V. Saveliev <[email protected]> wrote:
>> On Tue, 2006-08-01 at 17:32 +0200, �ukasz Mierzwa wrote:
>> > Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds
>> <[email protected]>
>> > napisał:
>> > > In other words, if a filesystem wants to do something fancy, it
>> needs to
>> > > do so WITH THE VFS LAYER, not as some plugin architecture of its
>> own. We
>> > > already have exactly the plugin interface we need, and it literally
>> _is_
>> > > the VFS interfaces - you can plug in your own filesystems with
>> > > "register_filesystem()", which in turn indirectly allows you to
>> plug in
>> > > your per-file and per-directory operations for things like lookup
>> etc.
>
>> > What fancy (beside cryptocompress) does reiser4 do now?
>>
>> it is supposed to provide an ability to easy modify filesystem behaviour
>> in various aspects without breaking compatibility.
>
> If it just modifies /behaviour/ it can't really do much. And what can be
> done here is more the job of the scheduler, not of the filesystem. Keep
> your
> hands off it!
You modify the way the fs stores files or let You access them, since when
it is a job for a scheduler?
> If it somehow modifies /on disk format/, it (by *definition*) isn't
> compatible. Ditto.
>
>> > Can someone point me to a list of things that are required by kernel
>> > mainteiners to merge reiser4 into vanilla?
>>
>> list of features reiser4 does not have now:
>> O_DIRECT support - we are working on it now
>> various block size support
>
> Is this required?
>
>> quota support
>> xattrs and acls
>
> Without those, it is next to useless anyway.
I don't use any of this and I live quite happly.
Horst H. von Brand wrote:
> Vladimir V. Saveliev <[email protected]> wrote:
>> On Tue, 2006-08-01 at 17:32 +0200, Åukasz Mierzwa wrote:
>>> What fancy (beside cryptocompress) does reiser4 do now?
>> it is supposed to provide an ability to easy modify filesystem behaviour
>> in various aspects without breaking compatibility.
>
> If it just modifies /behaviour/ it can't really do much. And what can be
> done here is more the job of the scheduler, not of the filesystem. Keep your
> hands off it!
Say wha?
There's a lot you can do with the _representation_ of the on-disk format
without changing the _physical_ on-disk format. As a very simple
example, a plugin could add a sysfs-like folder with information about
that particular filesystem. Yes, I know there are better ways to do
things, but there are things you can change about behavior without (I
think) touching the scheduler.
Or am I wrong about the scope of the "scheduler"?
> If it somehow modifies /on disk format/, it (by *definition*) isn't
> compatible. Ditto.
Cryptocompress is compatible with kernels that have a working
cryptocompress plugin. Other kernels will notice that they are meant to
be read by cryptocompress, and (I hope) refuse to read files they won't
be able to.
Same would be true of any plugin that changes the disk format.
But, the above comments about behavior still hold. There's a lot you
can do with plugins without changing the on-disk format. If you want a
working example, look to your own favorite filesystems that support
quotas, xattrs, and acls -- is an on-disk FS format with those enabled
compatible with a kernel that doesn't support them (has them turned
off)? How about ext3, with its journaling -- is the journaling all in
the scheduler? But isn't the ext3 disk format compatible with ext2?
>> quota support
>> xattrs and acls
>
> Without those, it is next to useless anyway.
What is? The FS? I use neither on desktop machines, though I'd
appreciate xattrs for Beagle.
Or are you talking about the plugins? See above, then.