On Mon, Jun 08, 2009 at 10:02:52AM +0200, Christoph Hellwig wrote: > Currently the superblock methods are a bit confusing. There is the > newer ->sync_fs method which is unconditionally called from > __sync_filesystem for data integrity writebacks. And there is the older > ->write_super which is called from pdflush for the periodic superblock > writeback, but also from __sync_filesystem just before calling > ->sync_fs. (And still from file_fsync, but that is about to go away). > > This series makes sure all filesystems that need superblock writeouts > define a ->sync_fs so we can stop calling ->write_super for the data > integrity writeback. This means the presence of ->write_super indicates > a filesystem does want periodic superblock writeback and can implement > these independently from the data integrity writeback. It also means > we don't need to bother with possible s_dirt races for the data > integrity syncs. > > This patch series first adds ->sync_fs methods to all filesystems having > ->write_super, often refactoring the code in that are (and also > preparing the ->write_super instances for moving MS_RDONLY checking into > the caller), then it makes sure the existing ->sync_fs instaces cover > the work previously done in ->write_super for the two cases where they > differed widely, and lastly removes the call to ->write_super from > __sync_filesystem. Applied. FWIW, file_fsync() is nearly gone; the last remnants are exofs, hfs and hfsplus. Is there any sane way to keep track of dirty metadata blocks there? Or is "just flush all dirty buffer_head for the device" really the best we can do? -- 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
