linux-kernel - Re: reiser4: maybe just fix bugs?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 31 Jul 2006 20:30:20 -0600
From:	Hans Reiser <reiser@...esys.com>
To:	Denis Vlasenko <vda.linux@...glemail.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: reiser4: maybe just fix bugs?

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