On Tue, Jan 04, 2011 at 05:04:52PM +1100, Nick Piggin wrote: > However I strongly believe that filesystems should be able to access > and manipulate the inode dirty state directly. If you agree with that, > then I think they should be able to access the lock required for that. > Filesystems will want to keep their internal state in synch with vfs > visible state most likely (eg. like your hfsplus patches), and _every_ > time we do "loose" coupling between state bits like this (eg. page and > buffer state; page and pte state; etc), it turns out to be a huge mess > of races and subtle code and ordering. I've probably done the two most complicated fsync implementations in xfs and hfsplys myself, and I'd really prefer the interface to be as simple as possible. The way the I_DIRTY_* flags and the datasync parameter to ->fsync interact are almost a receipe for getting it wrong, which in fact most implementations that tried to be smart did. See gfs2 and ocfs2 comments in this threads for classic examples. If we actually get filesystems that need to do smarts in checking/clearing the I_DIRTY_* flag we can discuss proper interfaces for it - duplicating guts of i_state manipulations sounds like a relatively bad idea for that. Note that my fsync_helper still gives filesystems a lot of information, just not in a redundant and confusing way. The dirty argument still tells if datasync-relevant or non-datasyns relevant (aka timestampts) metadata was dirty, so if a filesystem needs to write them back in different ways it still can. -- 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
