From: Peter Staubach <staubach@redhat.com>
To: Anton Salikhmetov <salikhmetov@gmail.com>
Cc: linux-mm@kvack.org, jakob@unthought.net,
linux-kernel@vger.kernel.org, Valdis.Kletnieks@vt.edu,
riel@redhat.com, ksm@42.dk, jesper.juhl@gmail.com
Subject: Re: [PATCH 2/2][RFC][BUG] msync: updating ctime and mtime at syncing
Date: Fri, 11 Jan 2008 16:59:41 -0500 [thread overview]
Message-ID: <4787E6CD.3080709@redhat.com> (raw)
In-Reply-To: <4df4ef0c0801111340n515a3c70n4b26468ddb47ebd2@mail.gmail.com>
Anton Salikhmetov wrote:
> 2008/1/11, Peter Staubach <staubach@redhat.com>:
>
>> Anton Salikhmetov wrote:
>>
>>> From: Anton Salikhmetov <salikhmetov@gmail.com>
>>>
>>> The patch contains changes for updating the ctime and mtime fields for memory mapped files:
>>>
>>> 1) adding a new flag triggering update of the inode data;
>>> 2) implementing a helper function for checking that flag and updating ctime and mtime;
>>> 3) updating time stamps for mapped files in sys_msync() and do_fsync().
>>>
>> Sorry, one other issue to throw out too -- an mmap'd block device
>> should also have its inode time fields updated. This is a little
>> tricky because the inode referenced via mapping->host isn't the
>> one that needs to have the time fields updated on.
>>
>> I have attached the patch that I submitted last. It is quite out
>> of date, but does show my attempt to resolve some of these issues.
>>
>
> Thanks for your feedback!
>
> Now I'm looking at your solution and thinking about which parts of it
> I could adapt to the infrastructure I'm trying to develop.
>
> However, I would like to address the block device case within
> a separate project. But for now, I want the msync() and fsync()
> system calls to update ctime and mtime at least for memory-mapped
> regular files properly. I feel that even this little improvement could address
> many customer's troubles such as the one Jacob Oestergaard reported
> in the bug #2645.
Not that I disagree and I also have customers who would really like
to see this situation addressed so that I can then fix it in RHEL,
but the block device issue was raised by Andrew Morton during my
first attempt to get a patch integrated.
Just so that you are aware of who has raised which issues... :-)
Thanx...
ps
WARNING: multiple messages have this Message-ID (diff)
From: Peter Staubach <staubach@redhat.com>
To: Anton Salikhmetov <salikhmetov@gmail.com>
Cc: linux-mm@kvack.org, jakob@unthought.net,
linux-kernel@vger.kernel.org, Valdis.Kletnieks@vt.edu,
riel@redhat.com, ksm@42.dk, jesper.juhl@gmail.com
Subject: Re: [PATCH 2/2][RFC][BUG] msync: updating ctime and mtime at syncing
Date: Fri, 11 Jan 2008 16:59:41 -0500 [thread overview]
Message-ID: <4787E6CD.3080709@redhat.com> (raw)
In-Reply-To: <4df4ef0c0801111340n515a3c70n4b26468ddb47ebd2@mail.gmail.com>
Anton Salikhmetov wrote:
> 2008/1/11, Peter Staubach <staubach@redhat.com>:
>
>> Anton Salikhmetov wrote:
>>
>>> From: Anton Salikhmetov <salikhmetov@gmail.com>
>>>
>>> The patch contains changes for updating the ctime and mtime fields for memory mapped files:
>>>
>>> 1) adding a new flag triggering update of the inode data;
>>> 2) implementing a helper function for checking that flag and updating ctime and mtime;
>>> 3) updating time stamps for mapped files in sys_msync() and do_fsync().
>>>
>> Sorry, one other issue to throw out too -- an mmap'd block device
>> should also have its inode time fields updated. This is a little
>> tricky because the inode referenced via mapping->host isn't the
>> one that needs to have the time fields updated on.
>>
>> I have attached the patch that I submitted last. It is quite out
>> of date, but does show my attempt to resolve some of these issues.
>>
>
> Thanks for your feedback!
>
> Now I'm looking at your solution and thinking about which parts of it
> I could adapt to the infrastructure I'm trying to develop.
>
> However, I would like to address the block device case within
> a separate project. But for now, I want the msync() and fsync()
> system calls to update ctime and mtime at least for memory-mapped
> regular files properly. I feel that even this little improvement could address
> many customer's troubles such as the one Jacob Oestergaard reported
> in the bug #2645.
Not that I disagree and I also have customers who would really like
to see this situation addressed so that I can then fix it in RHEL,
but the block device issue was raised by Andrew Morton during my
first attempt to get a patch integrated.
Just so that you are aware of who has raised which issues... :-)
Thanx...
ps
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-01-11 21:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1200006638.19293.42.camel@codedot>
2008-01-11 0:38 ` [PATCH 1/2][RFC][BUG] msync: massive code cleanup of sys_msync() Anton Salikhmetov
2008-01-11 0:38 ` Anton Salikhmetov, Anton Salikhmetov
2008-01-11 15:55 ` Rik van Riel
2008-01-11 15:55 ` Rik van Riel
2008-01-11 0:38 ` [PATCH 2/2][RFC][BUG] msync: updating ctime and mtime at syncing Anton Salikhmetov
2008-01-11 16:03 ` Rik van Riel
2008-01-11 0:44 ` Anton Salikhmetov
2008-01-11 0:44 ` Anton Salikhmetov, Anton Salikhmetov
2008-01-11 18:55 ` Peter Staubach
2008-01-11 18:55 ` Peter Staubach
2008-01-11 19:29 ` Anton Salikhmetov
2008-01-11 19:29 ` Anton Salikhmetov
2008-01-11 18:59 ` Peter Staubach
2008-01-11 21:40 ` Anton Salikhmetov
2008-01-11 21:40 ` Anton Salikhmetov
2008-01-11 21:59 ` Peter Staubach [this message]
2008-01-11 21:59 ` Peter Staubach
2008-01-11 22:15 ` Anton Salikhmetov
2008-01-11 22:15 ` Anton Salikhmetov
2008-01-12 2:24 ` Anton Salikhmetov
2008-01-12 2:24 ` Anton Salikhmetov
2008-01-12 9:36 ` Peter Zijlstra
2008-01-12 9:36 ` Peter Zijlstra
2008-01-12 9:40 ` Peter Zijlstra
2008-01-12 9:40 ` Peter Zijlstra
2008-01-12 12:38 ` Anton Salikhmetov
2008-01-12 12:38 ` Anton Salikhmetov
2008-01-12 13:09 ` Peter Zijlstra
2008-01-12 13:09 ` Peter Zijlstra
2008-01-12 13:51 ` Anton Salikhmetov
2008-01-12 13:51 ` Anton Salikhmetov
2008-01-12 12:17 ` Anton Salikhmetov
2008-01-12 12:17 ` Anton Salikhmetov
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=4787E6CD.3080709@redhat.com \
--to=staubach@redhat.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=jakob@unthought.net \
--cc=jesper.juhl@gmail.com \
--cc=ksm@42.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=salikhmetov@gmail.com \
/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.