> It's a very remote possability of failure, like most instances where
> write-cache would cause problems. Catastrophic failure of the IDE cable
> in mid-write will cause problems. If write cache is enabled, the write
> stands a higher chance of having made it to the drive before the cable
> died, with it off, it stands a higher chance of NOT having made it
> entirely to the drive.
Cables don't suddenly die without the help of e. g. your CPU fan.
> For most drives, I don't know for sure if they'd finish the write
> that's now sitting in their cache, but I expect higher quality drives
> (such as our IBM drives) definitely would. Infact I may even be willing
> to test this later (my swap partition looks like it wants to help :)
Drives would not write incomplete blocks.
> > It may be an implementation problem in our IBM drives which ship with
> > their write caches enabled, someone please do this test on current
> > Fujitsu, Maxtor or Seagate IDE drives or with different controllers.
>
> Either Maxtor or Western Digital share very close designs to IBM
> drives, I belive they had some sort of development partnership. I'm not
> sure if it was Maxtor or WD.
The Western Digital 420400D (20 GB, 5400/min) and its 7200/min brother
with 18 GBs were IBM disk drives, supposedly, but the WD ...AA/BB drives
and whatever else there was looked some different from IBM drives.
> > Why are disk drives slower with their caches disabled on LINEAR
> > writes?
>
> Maybe the cache isn't doing what we think it is?
Maybe. A monitor software or debug mode would be good to see when writes
are scheduled and which blocks are written (I need to ask a friend of
mine who hacked ll_rw_blk.c on a different purpose for his diploma
thesis, maybe his code is valuable to figure things out.)
> Does anyone have contacts at IBM and/or Western Digital? Something's
> up... The 256MB write with write-cache off was going at 5.8MB/sec, and
> with it on it was going at 14.22MB/sec (averages). One interesting
> thing, the timings are showing a pretty consistant but tiny increase in
> sys time with write caching on.
I also saw that here, but again, it's basically the same hardware.
-- Matthias Andree"Those who give up essential liberties for temporary safety deserve neither liberty nor safety." - Benjamin Franklin - 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/