linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1158166a0607310226m5e134307o8c6bedd1f883479c@mail.gmail.com>
Date:	Mon, 31 Jul 2006 10:26:55 +0100
From:	"Denis Vlasenko" <vda.linux@...glemail.com>
To:	reiser@...esys.com
Cc:	linux-kernel@...r.kernel.org
Subject: reiser4: maybe just fix bugs?

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
-
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/