On Thu, 01 Aug 2013 23:21:48 -0400, Greg Freemyer said: > I should know, but I don't think your question makes sense. Data transfers > are axles immediately upon receipt by the drive. When the drive actually puts > it to stable storage there is not another ack message. > I believe disk drives can typically cache a handful of tracks at a time. > They can do a elevator sort internally on the tracks so the right order is not > guarenteed but that has nothing to do with acks back to the driver. In fact, the way that disk drives will flat-out lie about what they're doing is a major challenge for filesystem designers. In every filesystem, there are places where things have to be committed to disk in a certain order for it to maintain logical consistency in case of a crash mid-operation. For instance, it's usually better to de-allocate blocks from a file, then add the blocks to the free list, because a crash in between the two steps results in blocks you can't allocate. That's better than the other way around, where after the crash you can re-allocate blocks off the free list and overwrite existing data... However, actual hardware is known to lie about *ALL* of the following: 1) Whether or not it has actually written a given block to disk. 2) What order writes happened in. 3) How large the disk's write buffer is (so you can't spam the drive with dummy writes to force eviction of a write you care about) 4) Whether the disk's buffer cache is write-through or write-behind. 5) Whether a cache-flush request has completed, or merely been accepted 6) Whether the battery backup on a disk cache is enabled and functional 7) Whether there actually is a battery backup or not 8) Whether a disk's write cache is enabled or not. 9) Whether a disk *has* a write cache or not. And that's just the hardware screw-ups that I've gotten burned by personally. There's an even longer list of stupid hardware tricks I've heard about from others over beers. ;) This is why good filesystem designers almost always burn out and resort to heavy drinking at a young age. ;)
Attachment:
pgpriTxuJwgKS.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
