On Tue 25-03-14 18:09:38, Benjamin LaHaise wrote: > On Sun, Mar 23, 2014 at 02:14:16PM +0100, Jan Kara wrote: > > So the dirty inode is almost certainly a block device inode. Another clue > > is that fsync(2) actually doesn't clean inode dirty state (especially not > > for block device inodes since that inode is a special one and fs usually > > doesn't get to inspecting it). sync(2) does in general clear inode dirty > > state because that's handled by flusher thread. However if ->sync_fs() > > dirties the block device inode, subsequent sync_blockdev() call only writes > > the data but doesn't clean the inode state. So even with sync(2) it can > > happen the block device inode remains dirty. > > > In general inode dirty state isn't reliable. I_DIRTY_DATA can be set when > > inode is in fact clean. You have to use mapping_tagged(inode->i_mapping, > > PAGECACHE_TAG_DIRTY) to determine whether the inode has actually any dirty > > data. > > That is indeed the case. I checked the contents of the inode, and none of > the buffers attached to that inode were dirty. > > Is there any desire to fix this? Seeing an inode on the b_dirty list that > isn't really an inode that contains any data doesn't make a whole lot of > sense. It doesn't make a lot of sense but this kind of lazy b_dirty management allows us to avoid synchronization issues with flusher working in the inode at the same time. So I'm not convinced we want to fix that... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
