Re: fsck error on flashcard with ext2 filesystem
From: Jan Kara
Date: Mon Mar 14 2005 - 05:01:54 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?
Hmm, are the kernels really vanilla kernels without any patches?
Anyway the problem was that on the system with flashcard old data were
still kept in the cache for userspace (userspace uses cache independent from
the one filesystem uses), so it could be anything starting by different
amount of memory and ending at a different timing/command sequence
> I was using fsck with "-n" option which doesnt executes the command, just
> shows what would be done. I thought it would be harmless.
Ok, that won't harm the filesystem but you can still see errors which
are not on the filesystem (because of the cache issues).
> -----Original Message-----
> From: Jan Kara [mailto:jack@xxxxxxx]
> Sent: Friday, March 11, 2005 6:37 AM
> To: Santosh Gupta
> Cc: linux-kernel@xxxxxxxxxxxxxxx
> 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
> > difference.
> > 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/