[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120220110627.GB6799@quack.suse.cz>
Date: Mon, 20 Feb 2012 12:06:27 +0100
From: Jan Kara <jack@...e.cz>
To: Alex Elder <elder@...amhost.com>
Cc: Jan Kara <jack@...e.cz>, LKML <linux-kernel@...r.kernel.org>,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Eric Sandeen <sandeen@...hat.com>,
Dave Chinner <david@...morbit.com>,
Sage Weil <sage@...dream.net>, ceph-devel@...r.kernel.org
Subject: Re: [PATCH 04/11] ceph: Push file_update_time() into
ceph_page_mkwrite()
On Thu 16-02-12 13:04:37, Alex Elder wrote:
> On Thu, 2012-02-16 at 14:46 +0100, Jan Kara wrote:
> > CC: Sage Weil <sage@...dream.net>
> > CC: ceph-devel@...r.kernel.org
> > Signed-off-by: Jan Kara <jack@...e.cz>
>
>
> This will update the timestamp even if a write
> fault fails, which is different from before.
>
> Hard to avoid though.
Yes. Relatively easy solution for this (at least for some filesystems)
is to include time update into other operations filesystem is doing.
Usually filesystem can do some preparations, then take page lock and then
update time stamps together with other things it wants to do. It usually
will be even faster than current scheme. But I decided to leave that to
fs maintainers because page_mkwrite() code tends to be tricky wrt locking
etc.
> Looks good to me.
>
> Signed-off-by: Alex Elder <elder@...amhost.com>
Thanks.
Honza
> > fs/ceph/addr.c | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
> > index 173b1d2..12b139f 100644
> > --- a/fs/ceph/addr.c
> > +++ b/fs/ceph/addr.c
> > @@ -1181,6 +1181,9 @@ static int ceph_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
> > loff_t size, len;
> > int ret;
> >
> > + /* Update time before taking page lock */
> > + file_update_time(vma->vm_file);
> > +
> > size = i_size_read(inode);
> > if (off + PAGE_CACHE_SIZE <= size)
> > len = PAGE_CACHE_SIZE;
>
>
>
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists