From: Pavel Machek <pavel@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>, mtk.manpages@gmail.com
Cc: Hugh Dickins <hugh@veritas.com>,
kernel list <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: sync_file_range(SYNC_FILE_RANGE_WRITE) blocks?
Date: Sun, 1 Jun 2008 13:40:09 +0200 [thread overview]
Message-ID: <20080601114008.GC16843@elf.ucw.cz> (raw)
In-Reply-To: <20080601011501.199af80c.akpm@linux-foundation.org>
Hi!
> > > > All I can say so far is that I find the same as you do:
> > > > SYNC_FILE_RANGE_WRITE (after writing) takes a significant amount of time,
> > > > more than half as long as when you add in SYNC_FILE_RANGE_WAIT_AFTER too.
> > > >
> > > > Which make the sync_file_range call pretty pointless: your usage seems
> > > > perfectly reasonable to me, but somehow we've broken its behaviour.
> > > > I'll be investigating ...
> > >
> > > It will block on disk queue fullness - sysrq-W will tell.
> >
> > Ah, thank you. What a disappointment, though it's understandable.
> > Doesn't that very severely limit the usefulness of the system call?
>
> A bit. The request queue size is runtime tunable though.
Which /sys is that? What happens if I set the queue size to pretty
much infinity, will memory management die horribly?
> I expect major users of this system call will be applications which do
> small-sized overwrites into large files, mainly databases. That is,
> once the application developers discover its existence. I'm still
> getting expressions of wonder from people who I tell about the
> five-year-old fadvise().
Hey, you have one user now, its called s2disk. But for this call to be
useful, we'd need asynchronous variant... is there such thing?
Okay, I can fork and do the call from another process, but...
> > I admit the flag isn't called SYNC_FILE_RANGE_WRITE_WITHOUT_WAITING,
> > but I don't suppose Pavel and I are the only ones misled by it.
>
> Yup, this caveat/restriction should be in the manpage.
Michael, this is something for you I guess?
And andrew, something for you:
---
SYNC_FILE_RANGE_WRITE may and will block. Document that.
Signed-off-by: Pavel Machek <pavel@suse.cz>
---
commit 5db78da3d8e6fa527bfe384ded2ff7c835592fe2
tree 4c405e07be12f0a2260492fb43d19802ff7ebab1
parent 0ea376de01be797f9563c2c2464149f8f0af6329
author Pavel <pavel@amd.ucw.cz> Sun, 01 Jun 2008 13:39:25 +0200
committer Pavel <pavel@amd.ucw.cz> Sun, 01 Jun 2008 13:39:25 +0200
fs/sync.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/sync.c b/fs/sync.c
index 228e17b..54e9f20 100644
--- a/fs/sync.c
+++ b/fs/sync.c
@@ -139,7 +139,8 @@ asmlinkage long sys_fdatasync(unsigned i
* before performing the write.
*
* SYNC_FILE_RANGE_WRITE: initiate writeout of all those dirty pages in the
- * range which are not presently under writeback.
+ * range which are not presently under writeback. Notice that even this this
+ * may and will block if you attempt to write more than request queue size.
*
* SYNC_FILE_RANGE_WAIT_AFTER: wait upon writeout of all pages in the range
* after performing the write.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2008-06-01 11:39 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-30 10:26 sync_file_range(SYNC_FILE_RANGE_WRITE) blocks? Pavel Machek
2008-05-30 13:58 ` Hugh Dickins
2008-05-30 20:43 ` Pavel Machek
2008-05-31 18:44 ` Hugh Dickins
2008-06-01 0:39 ` Andrew Morton
2008-06-01 7:23 ` Hugh Dickins
2008-06-01 8:15 ` Andrew Morton
2008-06-01 11:40 ` Pavel Machek [this message]
2008-06-01 20:37 ` Andrew Morton
2008-06-01 22:00 ` Rafael J. Wysocki
2008-06-01 22:22 ` Pavel Machek
2008-06-01 22:47 ` Andrew Morton
2008-06-01 23:00 ` Pavel Machek
2008-06-01 23:11 ` Andrew Morton
2008-06-02 8:43 ` Hugh Dickins
2008-06-02 11:18 ` Rafael J. Wysocki
2008-06-02 12:11 ` Hugh Dickins
2008-06-02 11:43 ` Jens Axboe
2008-06-02 12:40 ` Hugh Dickins
2008-06-16 20:53 ` Rik van Riel
2008-06-17 4:54 ` Andrew Morton
2008-06-17 13:38 ` Rik van Riel
2008-06-02 16:50 ` Andrew Morton
2008-06-03 8:01 ` Michael Kerrisk
2008-06-03 8:05 ` Pavel Machek
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=20080601114008.GC16843@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=rjw@sisk.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.