On Thu, Jul 21, 2011 at 12:00:12AM +0200, Jan Kara wrote: > > Removing this call breaks sys_syncfs and similar semantics on filesystem > > just pushing metadata into buffers in ->write_inode or ->sync_fs and > > then expecting the caller to write them out. This list of filesystem > > includes ext2 and in general most filesystems without journaling or > > similar technics. > Note that for sys_syncfs() the __sync_blockdev() has just moved from > __sync_filesystem() to sync_filesystem(). So nothing should change. Sorry, I missed that. > > I'm perfectly fine with pushing the sync_blockdev call into the > > filesystem for these, but we'll need a way to handle them. > Yes, calling sync_blockdev() from sync_fs() might actually make sence > (e.g. ext3 and ext4 don't need it) but I didn't want to go that far in > this patch. The more fine-grained we can split the patches, the better. It'll help to explain what we're doing to thise trying to figure out a few years down the road. > > At which point we could fold this code into a blkdev_sync_fs method for > > now. Long term we'll need to support multiple BDIs per SB anyway, at > > which point the code can go away again. > Ah, I had to think a bit before I understood what you mean :). It's kind > of elegant but also slightly subtle (it's not immediately obvious how > blockdevs are synced during sync when you look at the code). Umm, and you > don't have any guarantee in which order superblocks are on the sb list so > you could sync block devices before some filesystems are finished. So I > don't think using blkdev_sync_fs() is a good idea after all. This required calling sync_blkdev from ->sync_fs of those filesystems that actually need it as a pre-requisite of course. -- 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
