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 [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
