On Tue, Dec 02, 2014 at 01:20:33AM -0800, Christoph Hellwig wrote: > Why do you need the additional I_DIRTY flag? A "lesser" > __mark_inode_dirty should never override a stronger one. Agreed, will fix. > Otherwise this looks fine to me, except that I would split the default > implementation into a new generic_update_time helper. Sure, I can do that. > > XFS doesn't have a ->dirty_time yet, but that way XFS would be able to > > use the I_DIRTY_TIME flag to log the journal timestamps if it so > > desires, and perhaps drop the need for it to use update_time(). > > We will probably always need a ->update_time to proide proper locking > around the timestamp updates. Couldn't you let the VFS set the inode timesstamps and then have xfs's ->dirty_time(inode, I_DIRTY_TIME) copy the timestamps to the on-disk inode structure under the appropriate lock, or am I missing something? > In the current from the generic lazytime might even be a loss for XFS as > we're already really good at batching updates from multiple inodes in > the same cluster for the in-place writeback, so I really don't want > to just enable it without those optimizations without a lot of testing. Fair enough; it's not surprising that this might be much more effective as an optimization for ext4, for no other reason that timestamp updates are so much heavyweight for us. I suspect that it should be a win for btrfs, though, and it should definitely be a win for those file systems that don't use journalling at all. - 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