diff options
author | Robin H. Johnson <robbat2@gentoo.org> | 2006-06-12 21:50:25 +0100 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-06-12 13:55:52 -0700 |
commit | cfd95a9cf58cd9e92d4c23b5ee20b07a3d121477 (patch) | |
tree | 446977d54fcf1f9e3a5c3c2f6aea1f1b1ac2f806 /mm/page_io.c | |
parent | 5f856e8bdcf5936c9c13cb251dae770e6eeb06b6 (diff) | |
download | kernel_samsung_crespo-cfd95a9cf58cd9e92d4c23b5ee20b07a3d121477.zip kernel_samsung_crespo-cfd95a9cf58cd9e92d4c23b5ee20b07a3d121477.tar.gz kernel_samsung_crespo-cfd95a9cf58cd9e92d4c23b5ee20b07a3d121477.tar.bz2 |
[PATCH] tmpfs: time granularity fix for [acm]time going backwards
I noticed a strange behavior in a tmpfs file system the other day, while
building packages - occasionally, and seemingly at random, make decided to
rebuild a target. However, only on tmpfs.
A file would be created, and if checked, it had a sub-second timestamp.
However, after an utimes related call where sub-seconds should be set, they
were zeroed instead. In the case that a file was created, and utimes(...,NULL)
was used on it in the same second, the timestamp on the file moved backwards.
After some digging, I found that this was being caused by tmpfs not having a
time granularity set, thus inheriting the default 1 second granularity.
Hugh adds: yes, we missed tmpfs when the s_time_gran mods went into 2.6.11.
Unfortunately, the granularity of CURRENT_TIME, often used in filesystems,
does not match the default granularity set by alloc_super. A few more such
discrepancies have been found, but this is the most important to fix now.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'mm/page_io.c')
0 files changed, 0 insertions, 0 deletions