From: Jens Axboe <jens.axboe@oracle.com>
To: Zhao Forrest <forrest.zhao@gmail.com>
Cc: Boaz Harrosh <bharrosh@panasas.com>,
Erez Zilber <erezzi.list@gmail.com>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Should a block device enforce block atomicity?
Date: Mon, 30 Jun 2008 10:55:56 +0200 [thread overview]
Message-ID: <20080630085556.GL20826@kernel.dk> (raw)
In-Reply-To: <ac8af0be0806300147i1970a6f7mb705c0ce590326@mail.gmail.com>
On Mon, Jun 30 2008, Zhao Forrest wrote:
> >
> > Don't forget that all IO requests are queued on the device. With a
> > modern HW and disk you usually have NCQ and most drives will throw
> > away write request to the same sector if they see a later write to
> > the same sector in the queue.
> >
> > That said. There is nothing wrong with writing again and again to
> > the same sector on disk. File/record locking is done at the FileSystem
> > level. An application that wants exclusive write need to open the file
> > that way. Other wise it could even be written from another machine not
> > even another thread.
> >
> > What is it you are concerned with?
> >
> I happen to read the email and have a question, that may not be Erez's
> real question :)
> Let's suppose the following example:
> 1 pdflush find a dirty inode and decides to flush a set of dirty pages
> to harddrive
> 2 while this set of dirty pages is being committed to
> harddrive(dma_mapping is done, but dirty pages are not really written
> to disk media), application/FS is trying to update some pages in this
> set of dirty pages.
>
> Then what happens? Will application be put into sleep until page
> flushing to disk media is done?
Yes, the page needs to be locked before IO can be issued. So it'll block
on the page lock. That is what I referred to as the page cache providing
this guarentee for you. With raw IO, the application needs to ensure
ordering on its own if it commits IO to the same block more than once.
--
Jens Axboe
prev parent reply other threads:[~2008-06-30 8:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-30 6:51 Should a block device enforce block atomicity? Erez Zilber
2008-06-30 6:55 ` Jens Axboe
2008-06-30 7:58 ` Erez Zilber
2008-06-30 8:24 ` Boaz Harrosh
2008-06-30 8:47 ` Zhao Forrest
2008-06-30 8:55 ` Jens Axboe [this message]
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=20080630085556.GL20826@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=bharrosh@panasas.com \
--cc=erezzi.list@gmail.com \
--cc=forrest.zhao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.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).