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

On Fri, Aug 2, 2013 at 1:32 AM, Rajat Sharma <fs.rajat@gmail.com> wrote:

On Fri, Aug 2, 2013 at 2:25 AM, neha naik <nehanaik27@gmail.com> wrote:

...

Hi, I have some conceptual questions about device driver :

1. Write order fidelity should be maintained when submitting requests from device driver to disk below. However, acknowledging these requests it is okay if we don't necessarily maintain that order, right?

Yes it should not matter as long as application can rely on data being written is in order of submission.

But it can't ..... unless the write cache is turned off and it is known the the cache is truly off. There is no guarantee of write order in the block stack. Not between the filesystem and the driver. Not between the driver and the drive. There are at least 2 elevators shuffling the order of writes to optimize performance. Rajat, did you get confused? Or were you trying to say something else? Greg

On Fri, Aug 2, 2013 at 5:10 PM, neha naik <nehanaik27@gmail.com> wrote:

Thanks for the responses. I have one more question for Greg. I come from filesystem background and not device driver so i may be a bit confused about the write order fidelity. I know that filesystems guarantee that.

Looking from filesystem perspective, no write will be allowed on the same block until the first write finishes. So, if 'B' is written after 'A' you can always guarantee that you will see 'B' at the end of the two writes.

I see what you are saying and that is totally different from what I was talking about. I am saying if userspace does: lseek(location_A), write(data_A) lseek(location_B), write(data_B) There is no guarantee which of those writes will be delivered to the device driver to perform first. The block layer has elevator logic that can optimize the physical write order.

Now imagine not having a filesystem, and doing a write directly on the device. Do device drivers honour it. Should they? I imagine device driver as a kind of queue. So any writes are always queued up one after the other so that it gives write order fidelity whether it wants to or not. Am i missing something here.

You seem to be talking about: lseek(location_A), write(data_A) lseek(location_A), write(data_B) That is a very special case and there is special logic to ensure data_B is the final write. So if you are only talking/thinking about overwrites of the exact same location, then you need to appreciate and clarify that you are talking about a special case. In the overwrite case, I believe the first write (data_A) can simply be consumed by the second write (data_B) and never even make it to the device driver. If it does get to the device driver, the disk drive might consolidate them to a single write of data_B to media.

Regards, Neha

Greg