On Fri, 18 Feb 2000, Stephen C. Tweedie wrote:
>Hi,
>
>On Thu, 17 Feb 2000 15:42:29 -0500 (EST), Mike Porter <mike@UDel.Edu>
>said:
>
>> I have seen one occurance of this on my machine - dual Pentium IIIs.
>> 2.3.43.
>
>> ls <file-name> would list the file.
>> ls -l <file-name> would generate an I/O error, as would any other
>> attempt to open the file.
>
>> Rebooted a day or two later (after my first occurance of seeing the
>> missing interrupt for /dev/hda for the first time ever - system
>> would not recover). fsck reported a bad/unused inode.
>
>That looks exactly like what I'd expect to see if the disk returned a
>bad block in the middle of an inode table. In particular, the
>filesystem is correctly returning a clean EIO error to the application
>rather than getting itself tied up in knots over the error.
>
>Looks like the kernel was working perfectly here...
Today I looked into this and I found a few ext2 and othe fses SMP races
and a genuine UP race in wait_on_inode (iget/iput). I also fixed the not
necessary double calling of clear_inode and added some commentary (see
mainly the fs.h commentary). I am been careful only about ext2 and nfs and
proc. I also checked fat and it seems to have its own locking so it should
work fine in SMP too (I haven't tried fat though). (right fix for proc
should be to change the proc_dir_entry->count to atomic_t but I didn't do
that to not bloat the patch with details, it can be trivially improved
with an incremental patch)
It applys cleanly on top of 2.3.47pre[26] and it fixes the popular 2.3.x
inode corruption (aka "rm: cannot remove file: Input/output errors").
ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.3/2.3.47pre2/inode-corruption-1.gz
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:25 EST