From: linux@horizon.com
To: miklos@szeredi.hu
Cc: akpm@linux-foundation.org, linux@horizon.com,
linux-kernel@vger.kernel.org, linux-mm@vger.kernel.org
Subject: Re: [patch resend v4] update ctime and mtime for mmaped write
Date: 27 Mar 2007 14:42:27 -0400 [thread overview]
Message-ID: <20070327184227.13923.qmail@science.horizon.com> (raw)
> Yes, this will make msync(MS_ASYNC) more heavyweight again. But if an
> application doesn't want to update the timestamps, it should just omit
> this call, since it does nothing else.
Er... FWIW, I have an application that makes heavy use of msync(MS_ASYNC)
and doesn't care about timestamps. (In fact, sometimes it's configured
to write to a raw device and there are no timestamps.)
It's used as a poor man's portable async I/O. The application logs
data to disk, and sometimes needs to sync it to disk to ensure it has
all been written.
To reduce long pauses when doing msync(MS_SYNC), it does msync(MS_ASYNC)
as soon as a page is filled up to prompt asynchronous writeback.
"I'm done writing this page and don't intend to write it again.
Please start committing it to stable storage, but don't block me."
Then, occasionally, there's an msync(MS_SYNC) call to be sure the data
is synced to disk. This caused annoying hiccups before the MS_ASYNC
calls were added.
I agree that msync(MS_ASYNC) has no semantics if time is ignored.
But it's a useful way to tell the OS that the page is not going
to be dirtied again.
next reply other threads:[~2007-03-27 18:42 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-27 18:42 linux [this message]
2007-03-27 18:55 ` Miklos Szeredi
2007-03-27 19:00 ` Miklos Szeredi
2007-03-27 19:05 ` Andrew Morton
2007-03-27 19:24 ` linux
2007-03-27 19:34 ` Andrew Morton
2007-03-27 20:09 ` linux
2007-03-27 20:31 ` Miklos Szeredi
2007-03-28 1:48 ` linux
2007-03-28 7:58 ` Nick Piggin
2007-03-28 9:50 ` linux
2007-03-29 4:59 ` Nick Piggin
2007-03-27 20:47 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2007-03-25 21:10 Miklos Szeredi
2007-03-26 21:00 ` Andrew Morton
2007-03-26 21:10 ` Matt Mackall
2007-03-26 22:25 ` Andrew Morton
2007-03-26 21:43 ` Miklos Szeredi
2007-03-26 22:31 ` Andrew Morton
2007-03-27 6:55 ` Miklos Szeredi
2007-03-27 7:22 ` Andrew Morton
2007-03-27 7:36 ` Miklos Szeredi
2007-03-27 7:49 ` Andrew Morton
2007-03-27 8:03 ` Miklos Szeredi
2007-03-27 8:18 ` Andrew Morton
2007-03-27 8:28 ` Miklos Szeredi
2007-03-27 8:51 ` Andrew Morton
2007-03-27 9:23 ` Miklos Szeredi
2007-03-27 17:52 ` Andrew Morton
2007-03-27 18:29 ` Miklos Szeredi
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=20070327184227.13923.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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
all inboxes | Powered by JetHome®