On Mon, 07 Jan 2008 20:54:19 +0300 Anton Salikhmetov <salikhmetov@gmail.com> wrote:As long as the ctime and mtime stamps change when the memory is written to, what exactly is the problem? Is it that the ctime and mtime does not change again when the memory is written to again? Is there a way for backup programs to miss file modification times? Could you explain (using short words and simple sentences) what the exact problem is? Eg. 1) program mmaps file 2) program writes to mmaped area 3) ??? <=== this part, in equally simple words :) 4) data loss An explanation like that will help people understand exactly what the bug is, and why the patch should be applied ASAP. Due to the various cleanups all being in one file, it took me a while to understand the patch. In an area of code this subtle, it may be better to submit the cleanups in (a) separate patch(es) from the patch that adds the call to file_update_time(). I wonder if calling file_update_time() from inside the loop is the best idea. Why not call that function just once, after msync breaks from the loop? thanks, Rik -- All Rights Reversed --
| Paul Jackson | Re: cpuset-remove-sched-domain-hooks-from-cpusets |
| James Bottomley | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| David Miller | Slow DOWN, please!!! |
| Masami Hiramatsu | Re: [RFC PATCH v4] Unified trace buffer |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Parag Warudkar | Re: 2.6.29-rc3: tg3 dead after resume |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
