Messages in this thread | | | Subject | Re: IDE DMA errors, massive disk corruption: Why? Fixed Yet? Whynot re-do failed op? | From | Valdis.Kletnieks@vt ... | Date | Tue, 07 Oct 2003 02:03:01 -0400 |
| |
On Tue, 07 Oct 2003 01:24:19 EDT, "Daniel B." said:
> So if some command/batch/etc. wasn't acknowledged, why can't the > kernel retry the command/batch/etc.?
The problem is that the disk ack'ed the command when the block went into the write cache. You *DONT* in general get back another ack when the block actually hits the platters.
> Given the serious of disk data corruption, why isn't the Linux kernel > more reliable here? Hasn't this family of IDE problems been around > for a couple of years now?
It's hard for the kernel to be more reliable unless you just disable the write cache.
The biggest reason we don't see more issues like this is that the average MTBF really is up in the 100K hours and up range, and most drives probably get around to actually writing all the blocks out every minute or so - so you're looking at literally a 1 in a million shot at corruption. Most of the time, it's writing back in-order enough that no badness happens - and with the rise of journaled file systems like ext3 and jfs and resierfs, the chance of actually getting bit by it drops even more (you'd have to hit a case where the blocks were re-ordered *and* the corresponding journal blocks didn't get written either).
Yes, this family of problems has been around ever since write caches were introduced. It's just taken until now that we've got file system code that's rock solid enough that the write cache is a major reliability issue - for the longest time, one kernel bug or another has been more of a concern. See the IDE corruption in early 2.5 kernels that scared a LOT of people away - I believe that one was done all by the kernel, without any help from the disk's write cache. ;) [unhandled content-type:application/pgp-signature] | |