On Thu, 28 May 2009 08:03:33 +0200 Nick Piggin <npiggin@xxxxxxx> wrote: > On Tue, May 26, 2009 at 11:06:21AM -0700, Stephen Hemminger wrote: > > The WARN_ON you introduced in > > fs: new inode i_state corruption fix > > > > Triggers every time during our regression test. The regression test runs > > on a VM under VMWare. Any ideas? > > Thanks. Adding linux-fsdevel. > > I guess you're mounting with -osync or -odirsync, or opening with O_SYNC? > > I think it's a false positive. The filesystem code syncs the inode to disk > just after creating it but before doing an unlock_new_inode on it to > clear I_NEW. I believe this should not result in any race, because it is > called by the guy who has created the inode and he never clears I_NEW. The > race came about when pdflush would be able to perform writeout in this > window, and non-atomic updates of i_state would race with the creator when > they are messing with i_state (without inode_lock held, because inode is > new). > > We could add some convoluted checks to try to allow for this, but I think > we might as well just rip out the checks... > > Would anyone prefer me to try to keep them? If not, I'll send a patch to > rip them out. You are right the file system is mounted on a virtual floppy device with -o sync. That explains it. This also explains why it only shows up in regression system (developers usually install the software). The floppy is useful for saving configuration when running off live cd. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
