lkml.org 
[lkml]   [2003]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: IDE DMA errors, massive disk corruption: Why? Fixed Yet? Whyn ot re-do failed op?
Date


> -----Original Message-----
> From: Daniel B. [mailto:dsb@smart.net]
> Sent: Monday, October 06, 2003 11:24 PM
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: IDE DMA errors, massive disk corruption: Why? Fixed Yet?
> Whynot re-do failed op?
>
> 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?

Normal writes are fire-and-forget. UDMA CRC errors are about the only place
you can catch this stuff with write cache on, but only then with
restrictions (see below). After a UDMA write, the drive goes busy then must
post ending status which represents the end-of-transfer status, not the
status of the write to the media. In theory, this should be catching your
problem.

However, here's the trick... Just because the drive is holding off good
status at the end of write number N (and hence no completion interrupt ---
I'm assuming the drive is working as intended, and intentionally not
generating IRQ...) doesn't mean that write N is the reason for holding off
that status. The disk could be trying to put write N-20938409283409234 on
the media and having an issue, recognize that it can't accept more write
data, and be choosing to hold off ending status instead of posting ready.
If a drive starts to recognize it needs to throttle the host, there are
several places for this to happen... and ending status on a DMA transfer is
one possible place. (Not a great choice, but it is possible...)

In that case, you're just toast, unless you have stored every write done in
the last 8 months in host buffer ram so you can retry them all.

> DMA-complete interrupts are probably how some of those
> acknowledgments
> are communicated, right?
>
> [munch]
>
> 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?

Actually, 48-bit LBA transfers (32MiB/command) opened a whole new can of
worms...

If you do a UDMA write exceeding the drive's cache size, and get a CRC error
at the end or any sort of DMA overrun/underrun, you have to assume that the
drive has just nuked the entire write space for that command. I'm sure we
could get around that problem if people were willing to pay for disk drives
with 32+MB buffers on them. (Actually we'd need a bit more to hold our own
runtime code and variables) However, they aren't.

From watching bus traces and the like, I'm pretty happy with the linux IDE
code. There are a *lot* of production machines out there with IDE drives in
them that aren't having these problems.

--eric


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.039 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site