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. -ben -- "Thought is the essence of where you are now." -- 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
