Thanks Jan,
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.
Thanks again.
Regards,
santosh
-----Original Message-----
From: Jan Kara [mailto:[EMAIL PROTECTED]
Sent: Friday, March 11, 2005 6:37 AM
To: Santosh Gupta
Cc: linux-kernel@vger.kernel.org
Subject: Re: fsck error on flashcard with ext2 filesystem
Hello,
just a reminder for the next time - please keep the lines length under 80
characters.
> 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.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
