RE: fsck error on flashcard with ext2 filesystem
From: Santosh Gupta
Date: Fri Mar 11 2005 - 15:07:06 EST
Although "sync" doesnt seem to make any difference to fsck output,
"blockdev --flushbufs" fixes the issue.
Still wondering why the flushing of buffer behavior is different on a
system with normal harddisk (Redhat 7.2 with 2.4.26 kernel ) as compared
to a system with flashcard (CoreLinux with 2.4.26 kernel) although the
system parameters/daemons are the same. I dont have to do sync or
blockdev --flushbufs on standard system. Any ideas?
I was using fsck with "-n" option which doesnt executes the command, just
shows what would be done. I thought it would be harmless.
From: Jan Kara [mailto:jack@xxxxxxx]
Sent: Friday, March 11, 2005 6:37 AM
To: Santosh Gupta
Subject: Re: fsck error on flashcard with ext2 filesystem
just a reminder for the next time - please keep the lines length under 80
> Detailed Description
> I am using Core Linux system on flashcard. Its another minimal linux
> distribution. Root filesystem is cramfs and a rw partition on flash is
> ext2. The system is always shutdown properly and initial fsck upon
> bootup shows no error. But if I delete a file on flash card and run
> fsck, it gives error in fsck. On umount and mounting again (or
> reboot), fsck shows no problem. Issuing "sync" command doesnt make any
> Why is the disk not getting updated with filesystem metadata even
> after I wait for so long?
Hmm, it may be a cache aliasing issue (anyway doing fsck on a mounted
filesystem is asking for a trouble and basically nobody promisses any
result). But you may try doing something like:
sync; blockdev --flushbufs
before a fsck.
Jan Kara <jack@xxxxxxx>
SuSE CR Labs
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/