Hi Chao, > > Now, we set flags of a newly created inode using set_cold_files() in > > advance of creating a new node page. By this, some inodes whose node > > page is not created yet can be linked into the global dirty list. > > > > If the checkpoint is executed at this moment, the inode will be written > > back by writeback_single_inode() and finally update_inode_page() will > > fail to detach the inode from the global dirty list because the inode > > doesn't have a node page. > > > > The problem is that the inode's state in VFS layer will become clean > > after execution of writeback_single_inode() and it's still linked in > > the global dirty list of f2fs and this will cause a kernel panic. > Before set_cold_files, In f2fs_new_inode, we will also dirty inode, so if > we only relocate code file initialization, would we suffer the same issue > due to below reason? If so, instead, how about check FI_NEW_INODE flag > during global dirty list flushing to decide whether we should flush that > inode? How do you think? > Thanks,
Oops, I missed f2fs_set_encrypted_inode() in f2fs_new_inode(), because we turned off the filesystem encryption feature. If we skip the inode which is set with FI_NEW_INODE flag during global dirty list flushing in block_operations(), we need to iterate again and again in block_operations() till the new inode is added to its parent inode and FI_NEW_INODE flag is cleared. How about that we don't do anything for the inode having FI_NEW_INODE flag in f2fs_mark_inode_dirty_sync() and invoke f2fs_mark_inode_dirty_sync() right after we clear FI_NEW_INODE flag in update_parent_metadata()? Thanks, ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
