John, I believe I fixed the bug you reported in "possible timestamp related
problem". Thanks for your help in reproducing the bug.
It was caused when reusing old inode times in a newly allocated inode, which
was active before, had some m/c/atimes in it, freed, and returned to the
inode cache: the older times were not reset, and if they were newer than the
current lower inode times, then they never reverted back. This only
happened on systems with not much memory, that use a lot of inodes over a
long enough period of time -- enough to cause the icache to recycle them.
The fix was simple, as the patch below shows. With this fix, I'm able to
built perl on your system several times for a few hours already; without the
fix, the build fails mid-way.
If I'm right, this should also fix two other reported bugs that
others have reported as file mtimes changing seemingly randomly:
https://bugzilla.fsl.cs.sunysb.edu/show_bug.cgi?id=575
https://bugzilla.fsl.cs.sunysb.edu/show_bug.cgi?id=578
Erez.
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 37fdc29..562880a 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -55,6 +55,14 @@ static void unionfs_read_inode(struct inode *inode)
inode->i_mapping->a_ops = &unionfs_aops;
+ /*
+ * reset times so unionfs_copy_attr_all can keep out time invariants
+ * right (upper inode time being the max of all lower ones).
+ */
+ inode->i_atime.tv_sec = inode->i_atime.tv_nsec = 0;
+ inode->i_mtime.tv_sec = inode->i_mtime.tv_nsec = 0;
+ inode->i_ctime.tv_sec = inode->i_ctime.tv_nsec = 0;
+
unionfs_read_unlock(inode->i_sb);
}
_______________________________________________
unionfs mailing list: http://unionfs.filesystems.org/
unionfs@mail.fsl.cs.sunysb.edu
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
