Conceptual questions about device driver

[Greg Freemyer]

On Fri, Aug 2, 2013 at 5:10 PM, neha naik <nehanaik27 at 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