Conceptual questions about device driver

neha naik nehanaik27 at gmail.com
Fri Aug 2 17:10:33 EDT 2013


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

Regards,
Neha


On Fri, Aug 2, 2013 at 1:56 PM, Greg Freemyer <greg.freemyer at gmail.com>wrote:

> On Fri, Aug 2, 2013 at 1:32 AM, Rajat Sharma <fs.rajat at gmail.com> wrote:
> > On Fri, Aug 2, 2013 at 2:25 AM, neha naik <nehanaik27 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130802/60d37068/attachment.html 


More information about the Kernelnewbies mailing list