Messages in this thread Patch in this message | | | Date | Mon, 12 Jun 2006 21:50:25 +0100 (BST) | From | Hugh Dickins <> | Subject | [PATCH] tmpfs: time granularity fix for [acm]time going backwards |
| |
From: Robin H. Johnson <robbat2@gentoo.org>
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> --- This patch should probably be included for 2.6.17, despite how long the bug has been around. It's a one-liner, with no side-effects.
mm/shmem.c | 1 + 1 file changed, 1 insertion(+)
--- 2.6.17-rc6-git/mm/shmem.c +++ linux/mm/shmem.c @@ -2102,6 +2102,7 @@ static int shmem_fill_super(struct super sb->s_blocksize_bits = PAGE_CACHE_SHIFT; sb->s_magic = TMPFS_MAGIC; sb->s_op = &shmem_ops; + sb->s_time_gran = 1; inode = shmem_get_inode(sb, S_IFDIR | mode, 0); if (!inode) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |