All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.