LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Anton Salikhmetov <salikhmetov@gmail.com>
Cc: Rik van Riel <riel@redhat.com>,
Valdis.Kletnieks@vt.edu, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps in msync()
Date: Thu, 10 Jan 2008 09:51:20 +0100 [thread overview]
Message-ID: <20080110085120.GK25527@unthought.net> (raw)
In-Reply-To: <4df4ef0c0801091603y2bf507e1q2b99971c6028d1f3@mail.gmail.com>
On Thu, Jan 10, 2008 at 03:03:03AM +0300, Anton Salikhmetov wrote:
...
> > I guess a third possible time (if we want to minimize the number of
> > updates) would be when natural syncing of the file data to disk, by
> > other things in the VM, would be about to clear the I_DIRTY_PAGES
> > flag on the inode. That way we do not need to remember any special
> > "we already flushed all dirty data, but we have not updated the mtime
> > and ctime yet" state.
> >
> > Does this sound reasonable?
>
> No, it doesn't. The msync() system call called with the MS_ASYNC flag
> should (the POSIX standard requires that) update the st_ctime and
> st_mtime stamps in the same manner as for the MS_SYNC flag. However,
> the current implementation of msync() doesn't call the do_fsync()
> function for the MS_ASYNC case. The msync() function may be called
> with the MS_ASYNC flag before "natural syncing".
If the update was done as Rik suggested, with the addition that msync()
triggered an explicit sync of the inode data, then everything would be ok,
right?
--
/ jakob
next prev parent reply other threads:[~2008-01-10 8:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-07 17:54 Anton Salikhmetov
2008-01-09 11:32 ` Anton Salikhmetov
2008-01-09 11:47 ` Jakob Oestergaard
2008-01-09 12:22 ` Jakob Oestergaard
2008-01-09 14:41 ` Jesper Juhl
2008-01-09 15:31 ` Anton Salikhmetov
2008-01-09 21:28 ` Peter Staubach
2008-01-09 20:50 ` Rik van Riel
2008-01-09 21:01 ` Klaus S. Madsen
2008-01-09 21:06 ` Valdis.Kletnieks
2008-01-09 22:06 ` Rik van Riel
2008-01-09 22:19 ` Peter Staubach
2008-01-09 22:33 ` Jakob Oestergaard
2008-01-09 23:41 ` Rik van Riel
2008-01-10 0:03 ` Anton Salikhmetov
2008-01-10 8:51 ` Jakob Oestergaard [this message]
2008-01-10 10:53 ` Anton Salikhmetov
2008-01-10 15:45 ` Rik van Riel
2008-01-10 15:56 ` Anton Salikhmetov
2008-01-10 16:07 ` Rik van Riel
2008-01-10 16:40 ` Anton Salikhmetov
2008-01-10 16:52 ` Peter Staubach
2008-01-10 16:46 ` Peter Staubach
2008-01-10 20:48 ` Valdis.Kletnieks
2008-01-10 0:48 ` Anton Salikhmetov
2008-01-10 0:40 ` Anton Salikhmetov
2008-01-09 21:18 ` Peter Staubach
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=20080110085120.GK25527@unthought.net \
--to=jakob@unthought.net \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=salikhmetov@gmail.com \
--subject='Re: [PATCH][RFC][BUG] updating the ctime and mtime time stamps in msync()' \
/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
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).