[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1HW7tS-0003em-00@dorka.pomaz.szeredi.hu>
Date: Tue, 27 Mar 2007 11:23:06 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: akpm@...ux-foundation.org
CC: a.p.zijlstra@...llo.nl, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [patch resend v4] update ctime and mtime for mmaped write
> > > > But Peter Staubach says a RH custumer has files written thorugh mmap,
> > > > which are not being backed up.
> > >
> > > Yes, I expect the backup problem is the major real-world hurt arising from
> > > this bug.
> > >
> > > But I expect we could adequately plug that problem at munmap()-time. Or,
> > > better, do_wp_page(). As I said - half-assed.
> > >
> > > It's a question if whether the backup problem is the only thing which is hurting
> > > in the real-world, or if people have other problems.
> > >
> > > (In fact, what's wrong with doing it in do_wp_page()?
> >
> > It's rather more expensive, than just toggling a bit.
>
> It shouldn't be, especially for filesystems which have one-second timestamp
> granularity.
>
> Filesystems which have s_time_gran=1 might hurt a bit, but no more than
> they will with write().
>
> Actually, no - we'd only update the mctime once per page per writeback
> period (30 seconds by default) so the load will be small.
Why? For each faulted page the times will be updated, no?
Maybe it's acceptable, I don't really know the cost of
file_update_time().
Tried this patch, and it seems to work. It will even randomly update
the time for tmpfs files (on initial fault, and on swapins).
Miklos
Index: linux/mm/memory.c
===================================================================
--- linux.orig/mm/memory.c 2007-03-27 11:04:40.000000000 +0200
+++ linux/mm/memory.c 2007-03-27 11:08:19.000000000 +0200
@@ -1664,6 +1664,8 @@ gotten:
unlock:
pte_unmap_unlock(page_table, ptl);
if (dirty_page) {
+ if (vma->vm_file)
+ file_update_time(vma->vm_file);
set_page_dirty_balance(dirty_page);
put_page(dirty_page);
}
@@ -2316,6 +2318,8 @@ retry:
unlock:
pte_unmap_unlock(page_table, ptl);
if (dirty_page) {
+ if (vma->vm_file)
+ file_update_time(vma->vm_file);
set_page_dirty_balance(dirty_page);
put_page(dirty_page);
}
-
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