Messages in this thread | | | Date | Sun, 2 Nov 2003 21:57:58 +0100 | From | Matthias Andree <> | Subject | Re: ide write cache issue? [Re: Something corrupts raid5 disks slightly during reboot] |
| |
On Sun, 02 Nov 2003, Ville Herva wrote:
> As an^Wthe IDE expert, can you clarify a few points: > > - How long can the unwritten data linger in the drive cache if the drive > is otherwise idle? (Without an explicit flush and with write caching > enabled.)
Several seconds. This is usually detailed in the OEM integrator manual, at least it used to be for several IBM and Fujitsu drives when I looked two years ago. Drives usually start flushing cached data before they go idle, and some drives guarantee maximum times before data hits the disk. IIRC, Fujitsu MAH drives (SCSI though, not ATA) for instance guarantee not to cache data for longer than 3 s, even if that means interrupting reordering writes and hits write performance adversely (because it might involve seeks). I seem to recall some IBM ATA drive claimed 15 s, but don't quote me on that, I don't even recall if that was 2.5" or 3.5".
I don't recall the exact wording, so it may mean that the drive will not VOLUNTARILY DELAY the write for more than 3 s. It's quite hard to write 4,096 scattered blocks on individual cylinders in 3 s even on 10,025/min drives and requires knowing the block offset from the current rotational angle of the platter... I wonder if drive firmware makes such scheduling efforts.
> I had unmounted the fs an raidstopped the md minutes before the boot.
Ugly if it still corrupts. :-(
> - Can this corruption happen on warmboot or only on poweroff?
On ATA drives, the cache contents must persist across soft or hard reset (warmboot).
> - What kind of corruption can one see the if boot takes place "too fast" > and drive hasn't got enough time to flush its cache?
None with intact drives and bug-free firmware (I doubt such a thing exists). Anyways, on powering down or with firmware bugs, anything is possible.
-- Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95 - 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/
| |