Messages in this thread | | | Date | Tue, 07 Oct 2003 01:24:19 -0400 | From | "Daniel B." <> | Subject | Re: IDE DMA errors, massive disk corruption: Why? Fixed Yet? Whynot re-do failed op? |
| |
Jeff Garzik wrote: > > Daniel B. wrote: > > If the kernel starts a write command for block 993, wouldn't it wait > > for a DMA interrupt signalling that the drive has received and accepted > > the command before the kernel starts the write command for block 10934? > > With command queueing, no, it would not wait.
Other than the write-back caching, it's not an open-loop system, right? Regardless of how commands are batched or queued, isn't there some acknowledgment back from the drive that some batch of commands (or some command, or some part of some command) was completed?
Surely the kernel checks for such acknowledgments, right?
DMA-complete interrupts are probably how some of those acknowledgments are communicated, right?
So if the kernel doesn't get an expected DMA interrupt, it should know that some command(/batch/part) wasn't acknowledged successfully, right? And surely it can tell _which_ command/batch/part wasn't acknowledged (if multiple ones can be outstanding), right?
So if some command/batch/etc. wasn't acknowledged, why can't the kernel retry the command/batch/etc.?
> > If it timed out waiting for that interrupt, can't it re-issue the > > write for block 993 before proceeding? > > Assuming a large amount of sanity in your OS driver... certainly.
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?
Daniel -- Daniel Barclay dsb@smart.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |