summaryrefslogtreecommitdiff
path: root/include/linux/sysctl.h
diff options
context:
space:
mode:
authorAndrew Morton <akpm@digeo.com>2002-12-14 03:17:26 -0800
committerJaroslav Kysela <perex@suse.cz>2002-12-14 03:17:26 -0800
commit75f19a4075dff845fbc1a2940c6aee9cd4891b2e (patch)
tree0d7f53f2781717d031af349742a58094bea98ea8 /include/linux/sysctl.h
parent7404e32c0f2dbd8cbca0126d7a46099ff1c4d57d (diff)
[PATCH] Add a sync_fs super_block operation
This is infrastructure for fixing the journalled-data ext3 unmount data loss problem. It was sent for comment to linux-fsdevel a week ago; there was none. Add a `sync_fs' superblock operation whose mandate is to perform filesystem-specific operations to ensure a successful sync. It is called in two places: 1: fsync_super() - for umount. 2: sys_sync() - for global sync. In the sys_sync() case we call all the ->write_super() methods first. write_super() is an async flushing operation. It should not block. After that, we call all the ->sync_fs functions. This is independent of the state of s_dirt! That was all confused up before, and in this patch ->write_super() and ->sync_fs() are quite separate. With ext3 as an example, the initial ->write_super() will start a transaction, but will not wait on it. (But only if s_dirt was set!) The first ->sync_fs() call will get the IO underway. The second ->sync_fs() call will wait on the IO. And we really do need to be this elaborate, because all the testing of s_dirt in there makes ->write_super() an unreliable way of detecting when the VFS is trying to sync the filesystem.
Diffstat (limited to 'include/linux/sysctl.h')
0 files changed, 0 insertions, 0 deletions