From: Pavel Machek <pavel@suse.cz>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
mtk.manpages@gmail.com, 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: Tue, 3 Jun 2008 10:05:15 +0200 [thread overview]
Message-ID: <20080603080515.GD27918@elf.ucw.cz> (raw)
In-Reply-To: <cfd18e0f0806030101x40e18f9do5e58784695cdaa46@mail.gmail.com>
On Tue 2008-06-03 10:01:22, Michael Kerrisk wrote:
> On Sun, Jun 1, 2008 at 1:40 PM, Pavel Machek <pavel@suse.cz> wrote:
> > 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?
>
> Pavel,
>
> Just to confirm: you are meaning that the sentence
>
> Notice that even this this may and will block if you attempt
> to write more than request queue size.
>
> should be added to the man page under the description of
> SYNC_FILE_RANGE_WRITE, right?
Yes.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
prev parent reply other threads:[~2008-06-03 17:17 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
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 [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=20080603080515.GD27918@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=mtk.manpages@googlemail.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.