Hi, On Fri, 18 Feb 2011 20:57:39 +0100, Philippe CHATAIGNON wrote: > Le Fri, 18 Feb 2011 16:21:45 +0900 (JST), > Ryusuke Konishi <ryusuke@xxxxxxxx> a écrit : > > Thank you for the cooperation. > > > > Yeah, this file is exactly the file that overrode > > "f5_20110125_202053.ts(0).Xcl" at cp15731. > > > > I don't know why the past inode overrode the latest inode. One > > possible explanation is that garbage collection caused this > > interference, and another is interference by a snapshot mount for the > > checkpoint 14444. > > > > Were you mounting the snapshot cp14444 when > > "f5_20110125_202053.ts(0).Xcl" was destroyed at cp15731 ? > > > > If not, dummy on-memory inodes used for the garbage collection seem > > suspicious to me. > > Hi, > the first time I used snapshot on this fs is when I lost a file > because of inode's reuse (my first mail). When file f5_...Xcl was > deleted at cp15731, cp14444 was not a ss and wasn't mounted. And there > were no ss on this fs (only cp). 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. > Tell me if you need additional information. This partition's size is > 200G and I'll need that space in a few days. 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). Thanks, Ryusuke Konishi -- 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
