Duane Griffin wrote:
> If it doesn't take into account own changes, then the -n command is > unable to produce even a slightly accurate resemblence of what would > happen if I did a real run. It takes into account some of them (such as reading data from the backup superblock if it detects corruption). Others will be irrelevent for further operations. Many reports will be accurate, especially fatal ones. I consider that useful, YMMV.
I've attached the output of a -n run, let's get some facts on the table. I would be very happy if someone knowledgeable would tell me something useful about it. I'm especially worried about the "70058 files, 39754 blocks used (0%)" message at the end of the e2fsck run.
Attachment:
fs_check_out.bz2
Description: BZip2 compressed data
- Follow-Ups:
- Re: ext3 corruption
- From: Theodore Tso <[email protected]>
- Re: ext3 corruption
- References:
- ext3 corruption
- From: "Molle Bestefich" <[email protected]>
- Re: ext3 corruption
- From: "linux-os \(Dick Johnson\)" <[email protected]>
- Re: ext3 corruption
- From: "Molle Bestefich" <[email protected]>
- Re: ext3 corruption
- From: Michael Loftis <[email protected]>
- Re: ext3 corruption
- From: "Molle Bestefich" <[email protected]>
- Re: ext3 corruption
- From: "Duane Griffin" <[email protected]>
- Re: ext3 corruption
- From: "Molle Bestefich" <[email protected]>
- Re: ext3 corruption
- From: "Molle Bestefich" <[email protected]>
- Re: ext3 corruption
- From: "Duane Griffin" <[email protected]>
- ext3 corruption
- Prev by Date: Re: Univeral Protocol Driver (using UNDI) in Linux
- Next by Date: Re: Urgent help needed on an NFS question, please help!!!
- Previous by thread: Re: ext3 corruption
- Next by thread: Re: ext3 corruption
- Index(es):