> I found GC never causes such interference. So, the inode corruption > was not caused neither by the snapshot mount nor GC. > > Now, I'm suspecting a race condition between the removal of > "f3_20110123_223247.ts" and creation of > "f5_20110125_202053.ts(0).Xcl". > > Even though "f3_20110123_223247.ts" was removed at cp14522 (2011-01-25 > 20:29:09) from the "capture" directory, it seems like actual removal > of the inode happened a bit later than that since the file size was > pretty big. On my computer, deletion of a .ts file takes ~ 4-6 seconds (~1s/1G). It may happend that a *.Xcl file is created during this time. I make a little test with that fs. During the deletion of the file f3_20110107_205154.ts (inode 16), in a another console, I touch a file about every second : The result : 19 -rw-r--r-- 1 philippe users 0 19 févr. 14:54 test1 20 -rw-r--r-- 1 philippe users 0 19 févr. 14:54 test2 22 -rw-r--r-- 1 philippe users 0 19 févr. 14:55 test3 23 -rw-r--r-- 1 philippe users 0 19 févr. 14:55 test4 16 -rw-r--r-- 1 philippe users 0 19 févr. 14:55 test5 test1, 2, 3, 4 were created instantaneously while the ts file was deleting. But not test5 : touch command waits ~ 2-3 seconds until the rm was finished on the other console. It has the same inode that the deleted file. At final, filesystem seems OK but this time zone where the created file reuse the old inode during a file deletion seems a good candidate for race condition. I ask myself : is it mandatory to reuse inode number in nilfs design ? > OK, but, please resend me the checkpoint list you pasted last week > before reusing the disk. The list looks like expired on the web > (sorry, it's missing on my PC). Here is the same checkpoint list that I pasted last week (not the actual) with no expiration time : http://dpaste.org/UmEb/ In fact, I will keep this partition and continue to use it. So I delete the 2 files that share the same inode (cf. my first mail). For the 2nd rm, I have the message : NILFS warning (device dm-0): nilfs_do_unlink: deleting nonexistent file (14), 0 I touch some files after that : 14 -rw-r--r-- 1 philippe users 0 19 févr. 14:58 test6 24 -rw-r--r-- 1 philippe users 0 19 févr. 14:58 test7 25 -rw-r--r-- 1 philippe users 0 19 févr. 14:59 test8 Filesystem seems OK and I will send a new mail if new trouble appears. Thanks for your help, Regards, PhC -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
