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