reiser4: maybe just fix bugs?

reiser4: maybe just fix bugs?

[Denis Vlasenko]

Hi Hans,

The reiser4 thread seem to be longer than usual.
Let me, a mere user, add some input.

It looks to me that delay with reiser4 acceptance
is caused by two different things.

First, reiser4 adds those plugins which many FS people
see as belonging to VFS layer rather than to particular FS.

And second, reiser team was a bit lax at fixing bugs.
Not too bad when compared to other FSes, but still.

When singled out, none of these things are bad enough to hold off
inclusion. However, combined impact of _both_ of them
did upset maintainers enough.

Frankly, on the first problem I think that you are right, Hans,
and putting plugins into VFS _now_ makes little sense because
we can't know whether anybody will ever want to have plugins
for some other FS, so requiring reiser people to do all the shuffling _now_
for questionable gain is simply not fair. It can be done later if needed.

It leaves you with the other option: remove the second problem.
Try to fix bugs. Including reiser3 ones.
I'm not saying that you are not doing this at all,
but I distinctly remember that some discussions (about locking
problems IIRC) were "brushed aside" by reiser people instead of plainly
admitting that problem exists and they will work on fixing it.

* What is that story about hash chain size limit?
  Is it present on reiser4 also? Will it be addressed?

For the problems I personally seen:

* I had 3 reiser3 partitions on a 32Mb RAM box, and massive inode
  updates (chown -R) ate all RAM and deadlocked the box.
  You adviced me to reduce journal size. It works,
  but shouldn't reiser do it dynamically on mount if needed?
  Are there any other known oom deadlocks?
* Does reiser still requires 100.00% defect-free media?
* Are there plans for making reiserfsck interface compatible with fsck?
  I mean, making it so that reiserfsck can be symlinked to fsck.reiser
  and it will work? Currently, there seems to be some incompatibility
  in command-line switches. (I will dig out details and send separately
  when I'll get back to my Linux box.)

P.S. I am a reiser3 user on all my boxes.
Thanks Hans for your work.
--
vda

Re: reiser4: maybe just fix bugs?

[Adrian Bunk]

On Mon, Jul 31, 2006 at 10:26:55AM +0100, Denis Vlasenko wrote:

> Hi Hans,
> 
> The reiser4 thread seem to be longer than usual.
> Let me, a mere user, add some input.
> 
> It looks to me that delay with reiser4 acceptance
> is caused by two different things.
> 
> First, reiser4 adds those plugins which many FS people
> see as belonging to VFS layer rather than to particular FS.
> 
> And second, reiser team was a bit lax at fixing bugs.
> Not too bad when compared to other FSes, but still.
> 
> When singled out, none of these things are bad enough to hold off
> inclusion. However, combined impact of _both_ of them
> did upset maintainers enough.
>...

This is a wrong impression.

The bug fixing of reiser4 is definitely better than the average in the 
kernel. If you wanted to get e.g. the SATA drivers removed from the 
kernel, bug handling might be a point in favor of the removal. But 
that's not a problem with reiser4.

[1] tries to give an overview of the actual problems with the reiser4 
inclusion.

> vda

cu
Adrian

[1] http://wiki.kernelnewbies.org/WhyReiser4IsNotIn

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

Re: reiser4: maybe just fix bugs?

[Horst H. von Brand]

Denis Vlasenko <vda.linux@googlemail.com> wrote:
> The reiser4 thread seem to be longer than usual.
> Let me, a mere user, add some input.

Please don't.

> It looks to me that delay with reiser4 acceptance
> is caused by two different things.
> 
> First, reiser4 adds those plugins which many FS people
> see as belonging to VFS layer rather than to particular FS.

Right.

> And second, reiser team was a bit lax at fixing bugs.

Right!

> Not too bad when compared to other FSes, but still.

How did you compare?

> When singled out, none of these things are bad enough to hold off
> inclusion. However, combined impact of _both_ of them
> did upset maintainers enough.

Plus a, lets say, less than cooperative overall attitude, and a marked
tendency to try to sneak changes in by political arm-twisting.

> Frankly, on the first problem I think that you are right, Hans, and
> putting plugins into VFS _now_ makes little sense because we can't know
> whether anybody will ever want to have plugins for some other FS, so
> requiring reiser people to do all the shuffling _now_ for questionable
> gain is simply not fair. It can be done later if needed.

You are wrong. ReiserFS has no "right" to be allowed into the kernel. If
the people in charge of maintaining the filesystem infrastructure of the
kernel say something about your patches, you either take heed (and so
increase your chance of being accepted someday), or stay out. It is /their/
game, after all.

> It leaves you with the other option: remove the second problem.

That has to be done regardless. Buggy code with authors that can't be
bothered to fix it just means more work for the (thinly spread) kernel
hackers, so it is an absolute no-no-no.
-- 
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

Re: reiser4: maybe just fix bugs?

[Denis Vlasenko]

On Monday 31 July 2006 18:17, Horst H. von Brand wrote:
> > Not too bad when compared to other FSes, but still.
> 
> How did you compare?

Because as I can see on lkml, other FSes also have deadlock-on-oom
bugs. Linus also talked about ext3 inodes being insanely big.

> > When singled out, none of these things are bad enough to hold off
> > inclusion. However, combined impact of _both_ of them
> > did upset maintainers enough.
> 
> Plus a, lets say, less than cooperative overall attitude, and a marked
> tendency to try to sneak changes in by political arm-twisting.

Yes, this is present to a degree.
 
> > Frankly, on the first problem I think that you are right, Hans, and
> > putting plugins into VFS _now_ makes little sense because we can't know
> > whether anybody will ever want to have plugins for some other FS, so
> > requiring reiser people to do all the shuffling _now_ for questionable
> > gain is simply not fair. It can be done later if needed.
> 
> You are wrong. ReiserFS has no "right" to be allowed into the kernel.

JBD is factored out. So far it was a wasted effort - nobody uses
JBD except ext3.
--
vda

Re: reiser4: maybe just fix bugs?

[Hans Reiser]

Andrew Morton wrote:

>On Mon, 31 Jul 2006 10:26:55 +0100
>"Denis Vlasenko" <vda.linux@googlemail.com> wrote:
>
>  
>
>>The reiser4 thread seem to be longer than usual.
>>    
>>
>
>Meanwhile here's poor old me trying to find another four hours to finish
>reviewing the thing.
>  
>
Thanks Andrew.

>The writeout code is ugly, although that's largely due to a mismatch between
>what reiser4 wants to do and what the VFS/MM expects it to do.
>
I agree --- both with it being ugly, and that being part of why.

>  If it
>works, we can live with it, although perhaps the VFS could be made smarter.
>  
>
I would be curious regarding any ideas on that.  Next time I read
through that code, I will keep in mind that you are open to making VFS
changes if it improves things, and I will try to get clever somehow and
send it by you.  Our squalloc code though is I must say the most
complicated and ugliest piece of code I ever worked on for which every
cumulative ugliness had a substantive performance advantage requiring us
to keep it.  If you spare yourself from reading that, it is
understandable to do so.

>I'd say that resier4's major problem is the lack of xattrs, acls and
>direct-io.  That's likely to significantly limit its vendor uptake.  (As
>might the copyright assignment thing, but is that a kernel.org concern?)
>  
>
Thanks to you and the batch write code, direct io support will now be
much easier to code, and it probably will get coded the soonest of those
features.  acls are on the todo list, but doing them right might require
solving a few additional issues (finishing the inheritance code, etc.)

>The plugins appear to be wildly misnamed - they're just an internal
>abstraction layer which permits later feature additions to be added in a
>clean and safe manner.  Certainly not worth all this fuss.
>
>Could I suggest that further technical critiques of reiser4 include a
>file-and-line reference?  That should ease the load on vger.
>
>Thanks.
>
>
>  
>

Re: reiser4: maybe just fix bugs?

[Hans Reiser]

Denis Vlasenko wrote:

> And second, reiser team was a bit lax at fixing bugs.
> Not too bad when compared to other FSes, but still.

If we feel a bug should be fixed without waiting for a major release
(98%+ of bugs), we try to fix it in 3 days, and usually succeed at
that.  Not all users agree with us that a given bug should wait for a
major release.

> Frankly, on the first problem I think that you are right, Hans,
> and putting plugins into VFS _now_ makes little sense because
> we can't know whether anybody will ever want to have plugins
> for some other FS, so requiring reiser people to do all the shuffling
> _now_
> for questionable gain is simply not fair. It can be done later if needed.
>
> It leaves you with the other option: remove the second problem.
> Try to fix bugs. Including reiser3 ones.
> I'm not saying that you are not doing this at all,
> but I distinctly remember that some discussions (about locking
> problems IIRC) were "brushed aside" by reiser people instead of plainly
> admitting that problem exists and they will work on fixing it.
>
> * What is that story about hash chain size limit?
>  Is it present on reiser4 also? Will it be addressed?

Now that we  (Nikita actually) solved it in Reiser4 by handling
duplicate keys  I now realize that I could have solved it in V3 years
ago if I had been brighter, but since V4 is ready I think it is better
to not destabilize code in V3 by changing things now.  It might touch a
lot of lines of code to fix in V3, Nikita would know better than I.

>
> For the problems I personally seen:
>
> * I had 3 reiser3 partitions on a 32Mb RAM box, and massive inode
>  updates (chown -R) ate all RAM and deadlocked the box.

This is VFS/VM not us.  You are right that it should be fixed, as it is
indicative of deep problems with the memory management code that require
fundamental changes.

>  You adviced me to reduce journal size. It works,
>  but shouldn't reiser do it dynamically on mount if needed?

Yes, it would be nice, could you email chris@suse.com about it?  This is
a feature that is ok to add to a stable branch, I cannot logically
define why but I feel it is so....   after much testing and a beta
though....   Note that V4 fixes this by using wandering logs.....

>  Are there any other known oom deadlocks?

That are specific to reiserfs rather than all of Linux, I think not.....

> * Does reiser still requires 100.00% defect-free media?

Not if you use device mapper.

> * Are there plans for making reiserfsck interface compatible with fsck?
>  I mean, making it so that reiserfsck can be symlinked to fsck.reiser
>  and it will work? Currently, there seems to be some incompatibility
>  in command-line switches. (I will dig out details and send separately
>  when I'll get back to my Linux box.)

Not sure what you mean.  Forgive me, I have not supervised fsck as
closely as other things.

>
> P.S. I am a reiser3 user on all my boxes.
> Thanks Hans for your work.
> -- 
> vda
>
>
Thank you for your suggestions and advice,

Hans

Re: reiser4: maybe just fix bugs?

[Andrew Morton]

On Mon, 31 Jul 2006 10:26:55 +0100
"Denis Vlasenko" <vda.linux@googlemail.com> wrote:

> The reiser4 thread seem to be longer than usual.

Meanwhile here's poor old me trying to find another four hours to finish
reviewing the thing.

The writeout code is ugly, although that's largely due to a mismatch between
what reiser4 wants to do and what the VFS/MM expects it to do.  If it
works, we can live with it, although perhaps the VFS could be made smarter.

I'd say that resier4's major problem is the lack of xattrs, acls and
direct-io.  That's likely to significantly limit its vendor uptake.  (As
might the copyright assignment thing, but is that a kernel.org concern?)

The plugins appear to be wildly misnamed - they're just an internal
abstraction layer which permits later feature additions to be added in a
clean and safe manner.  Certainly not worth all this fuss.

Could I suggest that further technical critiques of reiser4 include a
file-and-line reference?  That should ease the load on vger.

Thanks.

Re: reiser4: maybe just fix bugs?

[Pavel Machek]

Hi!

> > * Are there plans for making reiserfsck interface compatible with fsck?
> >  I mean, making it so that reiserfsck can be symlinked to fsck.reiser
> >  and it will work? Currently, there seems to be some incompatibility
> >  in command-line switches. (I will dig out details and send separately
> >  when I'll get back to my Linux box.)
> 
> Not sure what you mean.  Forgive me, I have not supervised fsck as
> closely as other things.

fsck.ext2/fsck.vfat/... follow some convention including naming,
command line switches, and behaviour.

Like fsck.ext2 /dev/something is enough to check the fielsystem.

reiserfsck is missnamed (should be fsck.reiser), and it likes to chat
with you -- which is unexpected for tools.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: reiser4: maybe just fix bugs?

[Vladimir V. Saveliev]

Hello

On Mon, 2006-07-31 at 20:18 -0600, Hans Reiser wrote:
> Andrew Morton wrote:

> >The writeout code is ugly, although that's largely due to a mismatch between
> >what reiser4 wants to do and what the VFS/MM expects it to do.

Yes. reiser4 writeouts atoms. Most of pages get into atoms via
sys_write. But pages dirtied via shared mapping do not. They get into
atoms in reiser4's writepages address space operation. That is why
reiser4_sync_inodes has two steps: on first one it calls
generic_sync_sb_inodes to call writepages for dirty inodes to capture
pages dirtied via shared mapping into atoms. Second step flushes atoms.

> >
> I agree --- both with it being ugly, and that being part of why.
> 
> >  If it
> >works, we can live with it, although perhaps the VFS could be made smarter.
> >  
> >
> I would be curious regarding any ideas on that.  Next time I read
> through that code, I will keep in mind that you are open to making VFS
> changes if it improves things, and I will try to get clever somehow and
> send it by you.  Our squalloc code though is I must say the most
> complicated and ugliest piece of code I ever worked on for which every
> cumulative ugliness had a substantive performance advantage requiring us
> to keep it.  If you spare yourself from reading that, it is
> understandable to do so.
> 
> >I'd say that resier4's major problem is the lack of xattrs, acls and
> >direct-io.  That's likely to significantly limit its vendor uptake. 

xattrs is really a problem.

Re: reiser4: maybe just fix bugs?

[Christoph Hellwig]

On Tue, Aug 01, 2006 at 01:31:04AM -0700, Andrew Morton wrote:
> On Mon, 31 Jul 2006 10:26:55 +0100
> "Denis Vlasenko" <vda.linux@googlemail.com> wrote:
> 
> > The reiser4 thread seem to be longer than usual.
> I'd say that resier4's major problem is the lack of xattrs, acls and
> direct-io.

I though the namesys folks finally switched to the generic read/write
code?  With that implementing direct I/O should become rather simple -
they need a get_block routines that deals with these writes aswell as the
reads mostly.

> The plugins appear to be wildly misnamed - they're just an internal
> abstraction layer which permits later feature additions to be added in a
> clean and safe manner.  Certainly not worth all this fuss.

That because the real plugins are long gone.  It's just that neither the
complainers nor the fanboys in this thread ever read the code or generally
had any clue of their own.

Re: reiser4: maybe just fix bugs?

[Nick Piggin]

Andrew Morton wrote:
> On Mon, 31 Jul 2006 10:26:55 +0100
> "Denis Vlasenko" <vda.linux@googlemail.com> wrote:
> 
> 
>>The reiser4 thread seem to be longer than usual.
> 
> 
> Meanwhile here's poor old me trying to find another four hours to finish
> reviewing the thing.
> 
> The writeout code is ugly, although that's largely due to a mismatch between
> what reiser4 wants to do and what the VFS/MM expects it to do.  If it
> works, we can live with it, although perhaps the VFS could be made smarter.
> 
> I'd say that resier4's major problem is the lack of xattrs, acls and
> direct-io.  That's likely to significantly limit its vendor uptake.  (As
> might the copyright assignment thing, but is that a kernel.org concern?)
> 
> The plugins appear to be wildly misnamed - they're just an internal
> abstraction layer which permits later feature additions to be added in a
> clean and safe manner.  Certainly not worth all this fuss.
> 
> Could I suggest that further technical critiques of reiser4 include a
> file-and-line reference?  That should ease the load on vger.

I haven't really reviewed it, but when I grepped through it last, I
found a few alarming things, like use of __put_page, trying to remove
pages from pagecache (duplicating parts of vmscan.c, plus bugs), and
taking tree_lock.

Mostly didn't look like big problems to fix, but should be fixed for
mm/ maintainers' sanity. Maybe it's better now, though.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: reiser4: maybe just fix bugs?

[Scott J. Harmon]

Pavel Machek wrote:
> Hi!
> 
>>> * Are there plans for making reiserfsck interface compatible with fsck?
>>>  I mean, making it so that reiserfsck can be symlinked to fsck.reiser
>>>  and it will work? Currently, there seems to be some incompatibility
>>>  in command-line switches. (I will dig out details and send separately
>>>  when I'll get back to my Linux box.)
>> Not sure what you mean.  Forgive me, I have not supervised fsck as
>> closely as other things.
> 
> fsck.ext2/fsck.vfat/... follow some convention including naming,
> command line switches, and behaviour.
> 
> Like fsck.ext2 /dev/something is enough to check the fielsystem.
> 
> reiserfsck is missnamed (should be fsck.reiser), and it likes to chat
> with you -- which is unexpected for tools.
> 								Pavel

Yeah, I would never imagine that for ext2 and ext3 fsck might be called
'e2fsck'. ;-)

Scott.
-- 
"Computer Science is no more about computers than astronomy is about
telescopes." - Edsger Dijkstra

Re: reiser4: maybe just fix bugs?

[Andrew Morton]

On Tue, 01 Aug 2006 15:24:37 +0400
"Vladimir V. Saveliev" <vs@namesys.com> wrote:

> > >The writeout code is ugly, although that's largely due to a mismatch between
> > >what reiser4 wants to do and what the VFS/MM expects it to do.
> 
> Yes. reiser4 writeouts atoms. Most of pages get into atoms via
> sys_write. But pages dirtied via shared mapping do not. They get into
> atoms in reiser4's writepages address space operation.

It think you mean ->writepage - reiser4 desn't implement ->writepages().

I assume you considered hooking into ->set_page_dirty() to do the
add-to-atom thing earlier on?

We'll merge mm-tracking-shared-dirty-pages.patch into 2.6.19-rc1, which
would make that approach considerably more successful, I expect. 
->set_page_dirty() is a bit awkward because it can be called under
spinlock.

Maybe comething could also be gained from the new
vm_operations_struct.page_mkwrite(), although that's less obvious...

> That is why
> reiser4_sync_inodes has two steps: on first one it calls
> generic_sync_sb_inodes to call writepages for dirty inodes to capture
> pages dirtied via shared mapping into atoms. Second step flushes atoms.
> 
> > >
> > I agree --- both with it being ugly, and that being part of why.
> > 
> > >  If it
> > >works, we can live with it, although perhaps the VFS could be made smarter.
> > >  
> > >
> > I would be curious regarding any ideas on that.  Next time I read
> > through that code, I will keep in mind that you are open to making VFS
> > changes if it improves things, and I will try to get clever somehow and
> > send it by you.  Our squalloc code though is I must say the most
> > complicated and ugliest piece of code I ever worked on for which every
> > cumulative ugliness had a substantive performance advantage requiring us
> > to keep it.  If you spare yourself from reading that, it is
> > understandable to do so.
> > 
> > >I'd say that resier4's major problem is the lack of xattrs, acls and
> > >direct-io.  That's likely to significantly limit its vendor uptake. 
> 
> xattrs is really a problem.

That's not good.  The ability to properly support SELinux is likely to be
important.

Re: reiser4: maybe just fix bugs?

[Andrew Morton]

On Tue, 01 Aug 2006 21:52:03 +1000
Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Andrew Morton wrote:
> > On Mon, 31 Jul 2006 10:26:55 +0100
> > "Denis Vlasenko" <vda.linux@googlemail.com> wrote:
> > 
> > 
> >>The reiser4 thread seem to be longer than usual.
> > 
> > 
> > Meanwhile here's poor old me trying to find another four hours to finish
> > reviewing the thing.
> > 
> > The writeout code is ugly, although that's largely due to a mismatch between
> > what reiser4 wants to do and what the VFS/MM expects it to do.  If it
> > works, we can live with it, although perhaps the VFS could be made smarter.
> > 
> > I'd say that resier4's major problem is the lack of xattrs, acls and
> > direct-io.  That's likely to significantly limit its vendor uptake.  (As
> > might the copyright assignment thing, but is that a kernel.org concern?)
> > 
> > The plugins appear to be wildly misnamed - they're just an internal
> > abstraction layer which permits later feature additions to be added in a
> > clean and safe manner.  Certainly not worth all this fuss.
> > 
> > Could I suggest that further technical critiques of reiser4 include a
> > file-and-line reference?  That should ease the load on vger.
> 
> I haven't really reviewed it, but when I grepped through it last, I
> found a few alarming things, like use of __put_page, trying to remove
> pages from pagecache (duplicating parts of vmscan.c, plus bugs), and
> taking tree_lock.

__put_page() has gone.

A lot of the VM duplication has gone.

tree_lock is still there a bit.  For two reasons:

a) A presently-unneeded duplication of the generic
   __set_page_dirty_nobuffers() and

b) Manipulation of the fake inode (I think).

   iirc the base problem here is that for whatever reason, the usual
   blockdev inode which filesystems use for metadata (ie: the pagecache
   which backs sb_bread(), etc) isn't suitable.  reiser4 wants to get a
   hold of its address_space ops, so it needs to create its own
   covers-all-the-partition, identify-mapped address_space.

> Mostly didn't look like big problems to fix, but should be fixed for
> mm/ maintainers' sanity. Maybe it's better now, though.

It's better.  More reviewing help is always appreciated ;)

Re: reiser4: maybe just fix bugs?

[Vladimir V. Saveliev]

Hello

On Tue, 2006-08-01 at 07:33 -0700, Andrew Morton wrote:
> On Tue, 01 Aug 2006 15:24:37 +0400
> "Vladimir V. Saveliev" <vs@namesys.com> wrote:
> 
> > > >The writeout code is ugly, although that's largely due to a mismatch between
> > > >what reiser4 wants to do and what the VFS/MM expects it to do.
> > 
> > Yes. reiser4 writeouts atoms. Most of pages get into atoms via
> > sys_write. But pages dirtied via shared mapping do not. They get into
> > atoms in reiser4's writepages address space operation.
> 
> It think you mean ->writepage - reiser4 desn't implement ->writepages().
> 

no.
there is one. It is reiser4/plugin/file/file.c:writepages_unix_file().

reiser4_writepage just kicks kernel thread (entd) which works similar to
reiser4_sync_inodes() (described earlier) and waits until several pages
(including the one reiser4_writepage is called with) are written.

> I assume you considered hooking into ->set_page_dirty() to do the
> add-to-atom thing earlier on?
> 

Currently, add-to-atom is not simple. It may require memory allocations
and disk i/o-s. I guess these are not supposed to be called in
->set_page_dirty(). That is why in reiser4_set_page_dirty we just mark
the page in mapping's tree and dealy adding to atoms until flush time.


> We'll merge mm-tracking-shared-dirty-pages.patch into 2.6.19-rc1, which
> would make that approach considerably more successful, I expect. 
> ->set_page_dirty() is a bit awkward because it can be called under
> spinlock.
> 
> Maybe comething could also be gained from the new
> vm_operations_struct.page_mkwrite(), although that's less obvious...
> 
> > That is why
> > reiser4_sync_inodes has two steps: on first one it calls
> > generic_sync_sb_inodes to call writepages for dirty inodes to capture
> > pages dirtied via shared mapping into atoms. Second step flushes atoms.
> > 
> > > >
> > > I agree --- both with it being ugly, and that being part of why.
> > > 
> > > >  If it
> > > >works, we can live with it, although perhaps the VFS could be made smarter.
> > > >  
> > > >
> > > I would be curious regarding any ideas on that.  Next time I read
> > > through that code, I will keep in mind that you are open to making VFS
> > > changes if it improves things, and I will try to get clever somehow and
> > > send it by you.  Our squalloc code though is I must say the most
> > > complicated and ugliest piece of code I ever worked on for which every
> > > cumulative ugliness had a substantive performance advantage requiring us
> > > to keep it.  If you spare yourself from reading that, it is
> > > understandable to do so.
> > > 
> > > >I'd say that resier4's major problem is the lack of xattrs, acls and
> > > >direct-io.  That's likely to significantly limit its vendor uptake. 
> > 
> > xattrs is really a problem.
> 
> That's not good.  The ability to properly support SELinux is likely to be
> important.
> 

Do you think that if reiser4 supported xattrs - it would increase its
chances on inclusion?

PS: what exactly did you refer to when you said that writeout code is
ugly?

Re: reiser4: maybe just fix bugs?

[Theodore Tso]

On Mon, Jul 31, 2006 at 10:06:42PM +0200, Denis Vlasenko wrote:
> > You are wrong. ReiserFS has no "right" to be allowed into the kernel.
> 
> JBD is factored out. So far it was a wasted effort - nobody uses
> JBD except ext3.

Not true.  ocfs2 uses the jbd layer....

					- Ted

Re: reiser4: maybe just fix bugs?

[David Masover]

Vladimir V. Saveliev wrote:

> Do you think that if reiser4 supported xattrs - it would increase its
> chances on inclusion?

Probably the opposite.

If I understand it right, the original Reiser4 model of file metadata is 
the file-as-directory stuff that caused such a furor the last big push 
for inclusion (search for "Silent semantic changes in Reiser4"):

foo.mp3/.../rwx    # permissions
foo.mp3/.../artist # part of the id3 tag

So I suspect xattrs would just be a different interface to this stuff, 
maybe just a subset of it (to prevent namespace collisions):

foo.mp3/.../xattr/ # contains files representing attributes

Of course, you'd be able to use the standard interface for 
getting/setting these.  The point is, I don't think Hans/Namesys wants 
to do this unless they're going to do it right, especially because they 
already have the file-as-dir stuff somewhat done.  Note that these are 
neither mutually exclusive nor mutually dependent -- you don't have to 
enable file-as-dir to make xattrs work.

I know it's not done yet, though.  I can understand Hans dragging his 
feet here, because xattrs and traditional acls are examples of things 
Reiser4 is supposed to eventually replace.

Anyway, if xattrs were done now, the only good that would come of it is 
building a userbase outside the vanilla kernel.  I can't see it as doing 
anything but hurting inclusion by introducing more confusion about 
"plugins".

I could be entirely wrong, though.  I speak for neither 
Hans/Namesys/reiserfs nor LKML.  Talk amongst yourselves...

Re: reiser4: maybe just fix bugs?

[Nate Diller]

On 8/1/06, Andrew Morton <akpm@osdl.org> wrote:
> On Tue, 01 Aug 2006 15:24:37 +0400
> "Vladimir V. Saveliev" <vs@namesys.com> wrote:
>
> > > >The writeout code is ugly, although that's largely due to a mismatch between
> > > >what reiser4 wants to do and what the VFS/MM expects it to do.
> >
> > Yes. reiser4 writeouts atoms. Most of pages get into atoms via
> > sys_write. But pages dirtied via shared mapping do not. They get into
> > atoms in reiser4's writepages address space operation.
>
> It think you mean ->writepage - reiser4 desn't implement ->writepages().
>
> I assume you considered hooking into ->set_page_dirty() to do the
> add-to-atom thing earlier on?
>
> We'll merge mm-tracking-shared-dirty-pages.patch into 2.6.19-rc1, which
> would make that approach considerably more successful, I expect.
> ->set_page_dirty() is a bit awkward because it can be called under
> spinlock.
>
> Maybe comething could also be gained from the new
> vm_operations_struct.page_mkwrite(), although that's less obvious...
>
> > That is why
> > reiser4_sync_inodes has two steps: on first one it calls
> > generic_sync_sb_inodes to call writepages for dirty inodes to capture
> > pages dirtied via shared mapping into atoms. Second step flushes atoms.
> >
> > > >
> > > I agree --- both with it being ugly, and that being part of why.
> > >
> > > >  If it
> > > >works, we can live with it, although perhaps the VFS could be made smarter.
> > > >
> > > >
> > > I would be curious regarding any ideas on that.  Next time I read
> > > through that code, I will keep in mind that you are open to making VFS
> > > changes if it improves things, and I will try to get clever somehow and
> > > send it by you.  Our squalloc code though is I must say the most
> > > complicated and ugliest piece of code I ever worked on for which every
> > > cumulative ugliness had a substantive performance advantage requiring us
> > > to keep it.  If you spare yourself from reading that, it is
> > > understandable to do so.
> > >
> > > >I'd say that resier4's major problem is the lack of xattrs, acls and
> > > >direct-io.  That's likely to significantly limit its vendor uptake.
> >
> > xattrs is really a problem.
>
> That's not good.  The ability to properly support SELinux is likely to be
> important.

i disagreee that it will be difficult.  unfortunately, the patch that
I am working on right now, which fixes the various reiser4 specific
functions to avoid using VFS data structures unless needed, is a
prerequisite to enabling xattrs.  creating it is a time of tedium for
me, and it will cause a bit of internal churn (1000 lines and
counting).  it's all in the fs/reiser4 directory though, and it should
cause minimal disruption, as far as runtime bugs introduced.

once that's taken care of, i will be delighted to enable xattr support
in a way that will make selinux and beagle and such run as expected,
and will have the added advantage of some major scalability
improvements for certain lookup and update operations.

NATE

Re: reiser4: maybe just fix bugs?

[Nate Diller]

On 8/1/06, David Masover <ninja@slaphack.com> wrote:
> Vladimir V. Saveliev wrote:
>
> > Do you think that if reiser4 supported xattrs - it would increase its
> > chances on inclusion?
>
> Probably the opposite.
>
> If I understand it right, the original Reiser4 model of file metadata is
> the file-as-directory stuff that caused such a furor the last big push
> for inclusion (search for "Silent semantic changes in Reiser4"):
>
> foo.mp3/.../rwx    # permissions
> foo.mp3/.../artist # part of the id3 tag
>
> So I suspect xattrs would just be a different interface to this stuff,
> maybe just a subset of it (to prevent namespace collisions):
>
> foo.mp3/.../xattr/ # contains files representing attributes
>
> Of course, you'd be able to use the standard interface for
> getting/setting these.  The point is, I don't think Hans/Namesys wants
> to do this unless they're going to do it right, especially because they
> already have the file-as-dir stuff somewhat done.  Note that these are
> neither mutually exclusive nor mutually dependent -- you don't have to
> enable file-as-dir to make xattrs work.
>
> I know it's not done yet, though.  I can understand Hans dragging his
> feet here, because xattrs and traditional acls are examples of things
> Reiser4 is supposed to eventually replace.
>
> Anyway, if xattrs were done now, the only good that would come of it is
> building a userbase outside the vanilla kernel.  I can't see it as doing
> anything but hurting inclusion by introducing more confusion about
> "plugins".
>
> I could be entirely wrong, though.  I speak for neither
> Hans/Namesys/reiserfs nor LKML.  Talk amongst yourselves...

i should clarify things a bit here.  yes, hans' goal is for there to
be no difference between the "xattr" namespace and the "readdir" one.
unfortunately, this is not feasible with the current VFS, and some
major work would have to be done to enable this without some
pathological cases cropping up.  some very smart people think that it
cannot be done at all.

xattr is a seperate VFS interface, which avoids those problems by
defining certain restrictions on how the 'files' which live in that
namespace can be manupulated.  for instance, hard links are
non-existent, and the 'mv' command cannot move a file between
different xattr namespaces.

enabling xattr would have no connection to the file-as-directory
stuff, and (without extra work) would not even allow access to the
things reiser4 defined in the '...' directory.  also enabling xattr in
the way i intend would in no way compromise hans' long-term vision.

HOWEVER, i *need* to point out that hans and i disagree somewhat on
the specifics here, and so i should say adamently "i don't speak here
on behalf of hans or namesys".

that won't stop me from submitting my own patch though :)

NATE

Re: reiser4: maybe just fix bugs?

[Andi Kleen]

Andrew Morton <akpm@osdl.org> writes:

> On Mon, 31 Jul 2006 10:26:55 +0100
> "Denis Vlasenko" <vda.linux@googlemail.com> wrote:
> 
> > The reiser4 thread seem to be longer than usual.
> 
> Meanwhile here's poor old me trying to find another four hours to finish
> reviewing the thing.

I took a quick look at it and I must say that most of the things
that tripped me up when I first looked at it a long time ago
are gone now.

I guess there could be still quite a lot of cleanup, but it already
looks much better.

-Andi

Re: reiser4: maybe just fix bugs?

[David Masover]

Nate Diller wrote:
> On 8/1/06, David Masover <ninja@slaphack.com> wrote:
>> Vladimir V. Saveliev wrote:

>> I could be entirely wrong, though.  I speak for neither
>> Hans/Namesys/reiserfs nor LKML.  Talk amongst yourselves...
> 
> i should clarify things a bit here.  yes, hans' goal is for there to
> be no difference between the "xattr" namespace and the "readdir" one.
> unfortunately, this is not feasible with the current VFS, and some
> major work would have to be done to enable this without some
> pathological cases cropping up.  some very smart people think that it
> cannot be done at all.

But an xattr interface should work just fine, even if the rest of the 
system is inaccessible (no readdir interface) -- preventing all these 
pathological problems, except the one where Hans implements it the way 
I'm thinking, and kernel people hate it.

Re: reiser4: maybe just fix bugs?

[Jan Engelhardt]

>> fsck.ext2/fsck.vfat/... follow some convention including naming,
>> command line switches, and behaviour.
>> 
>> Like fsck.ext2 /dev/something is enough to check the fielsystem.
>
>
>> reiserfsck is missnamed (should be fsck.reiser), and it likes to chat
>> with you -- which is unexpected for tools.
>
>Yeah, I would never imagine that for ext2 and ext3 fsck might be called
>'e2fsck'. ;-)

So everyone plays his game...

xfs_check
jfs_fsck
dosfsck

I don't see why reiserfsck should be out of line...



Jan Engelhardt
-- 

Re: reiser4: maybe just fix bugs?

[Denis Vlasenko]

On Tuesday 01 August 2006 04:30, Hans Reiser wrote:
> Denis Vlasenko wrote:
> > * Are there plans for making reiserfsck interface compatible with fsck?
> >  I mean, making it so that reiserfsck can be symlinked to fsck.reiser
> >  and it will work? Currently, there seems to be some incompatibility
> >  in command-line switches. (I will dig out details and send separately
> >  when I'll get back to my Linux box.)
> 
> Not sure what you mean.  Forgive me, I have not supervised fsck as
> closely as other things.

I just tested. reiserfsck from latest reiserfsprogs is compatible with
fsck. That is, I symlinked reiserfsck to fsck.reiserfs and on reboot
fsck -a ran "fsck.reiserfs <device>" for all my reiser3 partitions.

So this problem doesn't exist anymore. Thanks!

P.S. My fsck is from e2fsprogs-1.34.
--
vda

Re: reiser4: maybe just fix bugs?

[Theodore Tso]

On Tue, Aug 01, 2006 at 11:55:57AM -0500, David Masover wrote:
> 
> If I understand it right, the original Reiser4 model of file metadata is 
> the file-as-directory stuff that caused such a furor the last big push 
> for inclusion (search for "Silent semantic changes in Reiser4"):

The furor was caused by concerns Al Viro expressed about
locking/deadlock issues that reiser4 introduced.  

The bigger issue with xattr support is two-fold.  First of all, there
are the progams that are expecting the existing extended attribute
interface, and not implementing it will simply mean that as far as
Samba, and other applications, Reiser4 simply will not haved xattr
support.

More importantly are the system-level extended attributes, such as
those used by SELINUX, which by definition are not supposed to be
visible to the user at all, but only are supposed to be there for the
SELINUX (or some other kernel layer, in general) to access.   

Not supporting xattrs means that those distro's that use SELINUX by
default (i.e., RHEL, Fedora, etc.) won't want to use reiser4, because
SELINUX won't work on reiser4 filesytstems.

Whether or not Hans cares about this is up to him....

						- Ted

Re: reiser4: maybe just fix bugs?

[David Masover]

Theodore Tso wrote:
> On Tue, Aug 01, 2006 at 11:55:57AM -0500, David Masover wrote:
>> If I understand it right, the original Reiser4 model of file metadata is 
>> the file-as-directory stuff that caused such a furor the last big push 
>> for inclusion (search for "Silent semantic changes in Reiser4"):
> 
> The furor was caused by concerns Al Viro expressed about
> locking/deadlock issues that reiser4 introduced.  

Which, I believe, was about file-as-dir.  Which also had problems with 
things like directory loops.  That's sort of a disk space memory leak.

> The bigger issue with xattr support is two-fold.  First of all, there
> are the progams that are expecting the existing extended attribute
> interface,

Yeah...

> More importantly are the system-level extended attributes, such as
> those used by SELINUX, which by definition are not supposed to be
> visible to the user at all,

I don't see why either of these are issues.  The SELINUX stuff can be a 
plugin which doesn't necessarily have a user-level interface. 
Cryptocompress, for instance, exists independent of its user-level 
interface (probably the file-as-dir stuff), and will probably be 
implemented in some sort of stable form as a system-wide default for new 
files.

So, certainly metadata (xattrs) as a plugin could be implemented with no 
UI at all, or any given UI.

... Anyway, I still see no reason why these cannot be implemented in 
Reiser4, other than the possibility that if it uses "plugins", I 
guarantee that at least one or two people will hate the implementation 
for that reason alone.

> Not supporting xattrs means that those distro's that use SELINUX by
> default (i.e., RHEL, Fedora, etc.) won't want to use reiser4, because
> SELINUX won't work on reiser4 filesytstems.

Right.  So they will be implemented, eventually.

> Whether or not Hans cares about this is up to him....

He does, or he should.  Reiser4 needs every bit of acceptance it can get 
right now, as long as it can get them without compromising its goals or 
philosophy.  Extended attributes only compromise these because it 
provides less incentive to learn any other metadata interface that 
Reiser4 provides.  But that's irrelevant if Reiser4 doesn't gain enough 
acceptance due to lack of xattr support, anything it has will be 
irrelevant anyway.

So just as we provide the standard interface to Unix permissions (even 
though we intend to implement things like acls and views, and even 
though there was a file/.pseudo/rwx interface), we should provide the 
standard xattr interface, and the standard direct IO interface, and 
anything else that's practical.  Be a good, standard filesystem first, 
and an innovative filesystem second.