On Jan 12, 2013, at 10:36 PM, "Theodore Ts'o" <tytso@xxxxxxx> wrote: > On Fri, Jan 11, 2013 at 09:47:01AM -0600, Eric Sandeen wrote: >>> Zeroing the inode table but not setting the INODE_ZEROED flag >>> would not be harmful, but this seems to not be the case. >> >> we appear to be not zeroing the table, and not setting INODE_ZEROED. >> But we should have set INODE_UNINIT, or zeroed it, right? > > The flag names are confusing. INODE_ZEROED means that the inode table > is not zero'ed. Please tell me you said that backwards? > This is correct. > > INODE_UNINIT refers to the inode allocation bitmap not being > initialized, and what we are doing is correct as well. > > What we should be doing is making sure that we kick off the lazyinit > thread. So it's basically a missing call to > ext4_register_li_request(sb). > >> Hum, but lazyinit will take some time to complete; in this case >> we resized, unmounted, ran fsck and everything was a mess. Even if >> we'd started lazyinit I don't think that'ts enough, because we never >> flagged the group as uninit. > > But as near as I can tell, at least with the latest upstream kernel, > the flags are being set correctly. INODE_ZEROED is not being set, but > that's correct, because the inode table has not been zeroed. > > The real problem was the bug which was fixed by 93f905264; previous to > this commit, the unused inode count was incorrect. My fault for not > understanding the consequences of this bug. I was thinking in terms > of the e2fsck taking too long, but of course if there were previously > valid inodes in those blocks, e2fsck would in fact go crazy. So that > commit really should have been marked cc: stable@xxxxxxxxxxxxxxx. > If setting the unused inode count is enough, then I guess it's resolved... > Regards, > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
