Messages in this thread | | | Date | Mon, 30 Mar 2009 13:05:54 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Linux 2.6.29 |
| |
On Mon, 30 Mar 2009, Rik van Riel wrote: > > Maybe a stupid question, but aren't tracks so small compared to > the disk head that a physical head crash would take out multiple > tracks at once? (the last on I experienced here took out a major > part of the disk)
Probably. My experiences (not _that_ many drives, but more than one) have certainly been that I've never seen a _single_ read error.
> Another case I have seen years ago was me writing data to a disk > while it was still cold (I brought it home, plugged it in and > started using it). Once the drive came up to temperature, it > could no longer read the tracks it just wrote - maybe the disk > expanded by more than it is willing to seek around for tracks > due to thermal correction? Low level formatting the drive > made it work perfectly and I kept using it until it was just > too small to be useful :)
I've had one drive that just stopped spinning. On power-on, it would make these pitiful noises trying to get the platters to move, but not actually ever work. If I recall correctly, I got the data off it by letting it just cool down, then powering up (successfully) and transferring all the data I cared about off the disk. And then replacing the disk.
> > And my point is, IT MAKES SENSE to just do the elevator barrier, _without_ > > the drive command. > > No argument there. I have seen NCQ starvation on SATA disks, > with some requests sitting in the drive for seconds, while > the drive was busy handling hundreds of requests/second > elsewhere...
I _thought_ we stopped feeding new requests while the flush was active, so if you actually do a flush, that should never actually happen. But I didn't check.
Linus
| |