On Saturday 20 May 2006 07:27, Martin Jambor wrote: > Hi everybody, > > we are developing a filesystem and despite we hoped not to need to > patch the kernel I found out we may need to do that because of > implementation of sync super operation. However, I would be glad to > hear I am wrong and can get away without it. > > The problem is that we require sync_fs() super operation to be the > last executed part of the sys_sync() syscall implementation. In other > words, we need all inodes to be written before sync_fs() is called. > > Unfortunately, what Linux does is (roughly): > > sync_inodes_sb(sb, 0); > ... > sb->s_op->sync_fs(sb, 1); > ... > sync_inodes_sb(sb, 1); > > sync_inodes_sb(sb, 0) often doesn't write out all dirty > inodes. Because our sync_fs() finalizes writing out of metadata, this > does not work for us. > > What is more, I regularly encounter a situation when a part of a > directory operation (usually the directory) is written before > sync_fs() is called and the second part (a new inode, for example) > afterwards. This means that the filesystem is only half-synced and > also in an inconsistent state. > > Is there a different solution to this issue apart from patching the > kernel to make sync_inodes_sb() exported and calling it again from > within our sync_fs() with 1 as the second parameter? I recently started using sync_fs in YAFFS and found that there's been quite a bit of change in the VFS<-->fs sync interaction over the ages. My recommendation would be to not change the VFS. If you do then (a) you'll break somebody else or (b) you'll be broken again later when something else changes. I would suggest that you track and handle any fs internal state yourself so that you don't rely on exact sequences of execution in VFS. There are two ways I can think of doing this: 1) Maintain your own lists of private (fs-internal) data, at least for any dirty inodes so that you can handle any dirty inode data yourself. 2) On sync_fs, walk the inodes that hang off the sb and handle all the dirty inodes. -- Charles - 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
