Conceptual questions about device driver

[Valdis.Kletnieks@vt.edu (Valdis.Kletnieks at vt.edu)]

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. ;)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130802/18d854cc/attachment.bin