* Better fsck.reiser4 needed
@ 2006-09-06 8:01 Joe Feise
2006-09-06 9:04 ` Vladimir V. Saveliev
0 siblings, 1 reply; 4+ messages in thread
From: Joe Feise @ 2006-09-06 8:01 UTC (permalink / raw)
To: reiserfs-list
Hi,
It seems that fsck.reiser4 -a doesn't do anything. It doesn't even detect
corruption.
I had a /var corruption (reiser4 on /var) over the weekend, and since I was out
of town, the machine was hanging trying to go into multi-user mode for a day
before I could fix the corruption manually. An fsck that actually would do some
automatic repairs (e.g., like ext3 which I use as the root partition) would be
really helpful.
For now, I have resorted to --fix -y at bootup time for all my reiser4
partitions, but that's just a quick hack, and rather unsatisfactory.
Cheers,
-Joe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Better fsck.reiser4 needed
2006-09-06 8:01 Better fsck.reiser4 needed Joe Feise
@ 2006-09-06 9:04 ` Vladimir V. Saveliev
2006-09-06 14:36 ` Joe Feise
2006-09-06 18:24 ` Andreas Dilger
0 siblings, 2 replies; 4+ messages in thread
From: Vladimir V. Saveliev @ 2006-09-06 9:04 UTC (permalink / raw)
To: jfeise; +Cc: reiserfs-list
Hello
On Wednesday 06 September 2006 12:01, Joe Feise wrote:
> Hi,
>
> It seems that fsck.reiser4 -a doesn't do anything. It doesn't even detect
> corruption.
I think it is made that way with intention. If fsck.reiser4 -a did corruption
detection bootup process would take long time and users would not have the
main advantage of journalled filesystems - quick recovering after unclean
shutdown.
> I had a /var corruption (reiser4 on /var) over the weekend, and since I was
> out of town, the machine was hanging trying to go into multi-user mode
I guess here you got reiser4 bug where it hanged trying to access corrupted
partition instead of returning -EIO. Was there anything interesting in logs
and have you managed to catch them?
> for
> a day before I could fix the corruption manually. An fsck that actually
> would do some automatic repairs (e.g., like ext3 which I use as the root
> partition) would be really helpful.
> For now, I have resorted to --fix -y at bootup time for all my reiser4
> partitions, but that's just a quick hack, and rather unsatisfactory.
>
> Cheers,
> -Joe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Better fsck.reiser4 needed
2006-09-06 9:04 ` Vladimir V. Saveliev
@ 2006-09-06 14:36 ` Joe Feise
2006-09-06 18:24 ` Andreas Dilger
1 sibling, 0 replies; 4+ messages in thread
From: Joe Feise @ 2006-09-06 14:36 UTC (permalink / raw)
To: Vladimir V. Saveliev; +Cc: reiserfs-list
Vladimir V. Saveliev wrote on 09/06/06 02:04:
>> I had a /var corruption (reiser4 on /var) over the weekend, and since I was
>> out of town, the machine was hanging trying to go into multi-user mode
>
> I guess here you got reiser4 bug where it hanged trying to access corrupted
> partition instead of returning -EIO. Was there anything interesting in logs
> and have you managed to catch them?
Unfortunately, I didn't get any logs, since they are on the corrupted /var.
-Joe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Better fsck.reiser4 needed
2006-09-06 9:04 ` Vladimir V. Saveliev
2006-09-06 14:36 ` Joe Feise
@ 2006-09-06 18:24 ` Andreas Dilger
1 sibling, 0 replies; 4+ messages in thread
From: Andreas Dilger @ 2006-09-06 18:24 UTC (permalink / raw)
To: Vladimir V. Saveliev; +Cc: jfeise, reiserfs-list
On Sep 06, 2006 13:04 +0400, Vladimir V. Saveliev wrote:
> On Wednesday 06 September 2006 12:01, Joe Feise wrote:
> > It seems that fsck.reiser4 -a doesn't do anything. It doesn't even detect
> > corruption.
>
> I think it is made that way with intention. If fsck.reiser4 -a did corruption
> detection bootup process would take long time and users would not have the
> main advantage of journalled filesystems - quick recovering after unclean
> shutdown.
In e2fsck the boot-time check (-a) of ext3 only does very minimal checking:
- valid superblock
- valid journal superblock
- recover journal and any errors stored in the journal, transfer to superblock
- reverify superblock
- check if superblock recorded any metadata errors previously
At this point less than a second has normally passed and the e2fsck is done.
The kernel ext3 code can also do journal recovery, but this doesn't allow
e2fsck the chance to verify the superblock after the journal is recovered.
If the journal or filesystem superblock recorded an error in the
filesystem during the previous run (generally corruption of the metadata)
or is itself corrupt e2fsck will force a full check. Otherwise,
this corruption may cause endless panic+reboot cycles, or may lead to
cascading corruption of the rest of the filesystem (e.g. if allocation
bitmaps are corrupted).
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-09-06 18:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-06 8:01 Better fsck.reiser4 needed Joe Feise
2006-09-06 9:04 ` Vladimir V. Saveliev
2006-09-06 14:36 ` Joe Feise
2006-09-06 18:24 ` Andreas Dilger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.