Thanks a lot for the reply, it certainly helped. On 5/21/06, Charles Manning <manningc2@xxxxxxxxxxxxx> wrote:
On Saturday 20 May 2006 07:27, Martin Jambor wrote: > Hi everybody, > 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.
OK, I very much prefer not to have to patch the kernel too.
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.
Thanks, I should have probably thought about this myself. Does any in-tree file system implement such a list? I have hopefully eventually managed to implement one but avoiding races with deleting inodes was quite tricky so I would actually like to have a look whether there is an easier way that has escaped me.
2) On sync_fs, walk the inodes that hang off the sb and handle all the dirty inodes.
I guess this would actually result into something resembling sync_sb_inodes(). However, since __iget() is not exported as well and since I found using iget(), ilookup() and the like difficult when processing my own list, I rather resorted to the first option. However, if there is an example in any of the in-tree filesystems, I'll be happy to look at it. Thanks again, your reply really helped to solve the issue, Martin - 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
