RE: fsck error on flashcard with ext2 filesystem
Hi Jan, Please see comments inline. > 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 whatever... Its NOT a vanilla kernel. I patched it with some local ppp and crypto patch, turned on couple of kernel options and nothing else. The same patched kernel works fine (as described earlier in mail) on a normal Redhat 7.2 box. > 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:[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/
Re: fsck error on flashcard with ext2 filesystem
Hello, > 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 whatever... > 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:[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/
Re: fsck error on flashcard with ext2 filesystem
Hello, 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 whatever... 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:[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/
RE: fsck error on flashcard with ext2 filesystem
Hi Jan, Please see comments inline. 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 whatever... santosh Its NOT a vanilla kernel. I patched it with some local ppp and crypto patch, turned on couple of kernel options and nothing else. The same patched kernel works fine (as described earlier in mail) on a normal Redhat 7.2 box. /santosh 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:[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/
RE: fsck error on flashcard with ext2 filesystem
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/
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/
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/
RE: fsck error on flashcard with ext2 filesystem
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/
