From: fs.rajat@gmail.com (Rajat Sharma)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Conceptual questions about device driver
Date: Fri, 2 Aug 2013 21:39:30 -0700 [thread overview]
Message-ID: <6077710377709935096@unknownmsgid> (raw)
BTW I have not seen filesystem implementations doing write ordering for
direct IO unless a request merge is possible (different user credentials),
since you have mentioned you are from filesystem background, do you know
any such implimentation?
Rajat
------------------------------
From: Rajat Sharma
Sent: 03-08-2013 09:25
To: neha naik; Greg Freemyer
Cc: kernelnewbies
Subject: RE: Conceptual questions about device driver
If filesystem has to guarantee write ordering, it has to serialize write
request. So, only when 'A' is written to the block (completion received
from block driver) filesystem can dispatch 'B' not before that. Remember
that there could be failures too. So if 'A' is failed, request for 'B' is
pending, would a filesystem fail that too? I guess not. Usually page cache
absorbs such overwrites first than issues a single merged IO to block
device, but what about direct IO? If applications need consistency
guarantee against such failures, it should serialize writes. So to
summarize, write ordering effort from each layers
Block driver: none
Filesystem: best effort
Application: full
Rajat
------------------------------
From: neha naik
Sent: 03-08-2013 02:40
To: Greg Freemyer
Cc: Rajat Sharma; kernelnewbies
Subject: Re: Conceptual questions about device driver
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@gmail.com>wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130802/35c68f7c/attachment.html
next reply other threads:[~2013-08-03 4:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-03 4:39 Rajat Sharma [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-08-03 3:55 Conceptual questions about device driver Rajat Sharma
2013-08-01 20:55 neha naik
2013-08-02 3:21 ` Greg Freemyer
2013-08-02 14:24 ` Valdis.Kletnieks at vt.edu
2013-08-02 5:32 ` Rajat Sharma
2013-08-02 19:56 ` Greg Freemyer
2013-08-02 21:10 ` neha naik
2013-08-02 22:33 ` Greg Freemyer
2013-08-02 5:55 ` Kumar Amit Mehta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6077710377709935096@unknownmsgid \
--to=fs.rajat@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).