From: Andrew Morton <akpm@linux-foundation.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, viro@ZenIV.linux.org.uk,
linux-fsdevel@vger.kernel.org, hch@infradead.org,
trond.myklebust@fys.uio.no, jack@suse.cz
Subject: Re: [PATCH 1/8] vfs: Fix sys_sync() and fsync_super() reliability (version 4)
Date: Mon, 27 Apr 2009 12:38:25 -0700 [thread overview]
Message-ID: <20090427123825.d24dbbbc.akpm@linux-foundation.org> (raw)
In-Reply-To: <1240843435-1786-2-git-send-email-jack@suse.cz>
On Mon, 27 Apr 2009 16:43:48 +0200
Jan Kara <jack@suse.cz> wrote:
> So far, do_sync() called:
> sync_inodes(0);
> sync_supers();
> sync_filesystems(0);
> sync_filesystems(1);
> sync_inodes(1);
The description has me all confused.
> This ordering makes it kind of hard for filesystems as sync_inodes(0) need not
> submit all the IO (for example it skips inodes with I_SYNC set) so e.g. forcing
> transaction to disk in ->sync_fs() is not really enough.
Is not really enough for what?
sync_fs(wait==0) is not supposed to be reliable - it's an advice to the
fs that it should push as much "easy" writeback into the queue as
possible. We'll do the real sync later, with sync_fs(wait==1).
> Therefore sys_sync has
> not been completely reliable on some filesystems (ext3, ext4, reiserfs, ocfs2
> and others are hit by this) when racing e.g. with background writeback.
No sync can ever be reliable in the presence of concurrent write
activity, unless we freeze userspace.
> A
> similar problem hits also other filesystems (e.g. ext2) because of
> write_supers() being called before the sync_inodes(1).
>
> Change the ordering of calls in do_sync() - this requires a new function
> sync_blkdevs() to preserve the property that block devices are always synced
> after write_super() / sync_fs() call.
>
> The same issue is fixed in __fsync_super() function used on umount /
> remount read-only.
So it's all a bit unclear (to me) what this patch is trying to fix?
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
> fs/super.c | 27 ++++++++++++++++++++++++++-
> fs/sync.c | 3 ++-
> include/linux/fs.h | 2 ++
> 3 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/fs/super.c b/fs/super.c
> index 786fe7d..4826540 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -267,6 +267,7 @@ void __fsync_super(struct super_block *sb)
> {
> sync_inodes_sb(sb, 0);
> vfs_dq_sync(sb);
> + sync_inodes_sb(sb, 1);
> lock_super(sb);
> if (sb->s_dirt && sb->s_op->write_super)
> sb->s_op->write_super(sb);
> @@ -274,7 +275,6 @@ void __fsync_super(struct super_block *sb)
> if (sb->s_op->sync_fs)
> sb->s_op->sync_fs(sb, 1);
> sync_blockdev(sb->s_bdev);
> - sync_inodes_sb(sb, 1);
> }
>
> /*
> @@ -502,6 +502,31 @@ restart:
> mutex_unlock(&mutex);
> }
>
> +/*
> + * Sync all block devices underlying some superblock
> + */
> +void sync_blockdevs(void)
> +{
> + struct super_block *sb;
> +
> + spin_lock(&sb_lock);
> +restart:
> + list_for_each_entry(sb, &super_blocks, s_list) {
> + if (!sb->s_bdev)
> + continue;
> + sb->s_count++;
> + spin_unlock(&sb_lock);
> + down_read(&sb->s_umount);
> + if (sb->s_root)
> + sync_blockdev(sb->s_bdev);
> + up_read(&sb->s_umount);
> + spin_lock(&sb_lock);
> + if (__put_super_and_need_restart(sb))
> + goto restart;
> + }
> + spin_unlock(&sb_lock);
> +}
The comment doesn't match the implementation. This function syncs all
blockdevs underlying _all_ superblocks.
next prev parent reply other threads:[~2009-04-27 19:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 14:43 [PATCH 0/8] Sync fixes and cleanups (version 4) Jan Kara
2009-04-27 14:43 ` [PATCH 1/8] vfs: Fix sys_sync() and fsync_super() reliability " Jan Kara
2009-04-27 19:38 ` Andrew Morton [this message]
2009-04-28 11:56 ` Jan Kara
2009-04-27 14:43 ` [PATCH 2/8] vfs: Call ->sync_fs() even if s_dirt is 0 " Jan Kara
2009-04-27 14:43 ` [PATCH 3/8] vfs: Make __fsync_super() a static function " Jan Kara
2009-04-27 14:43 ` [PATCH 4/8] vfs: Make sys_sync() use fsync_super() " Jan Kara
2009-04-27 14:43 ` [PATCH 5/8] vfs: Move syncing code from super.c to sync.c " Jan Kara
2009-04-27 14:43 ` [PATCH 6/8] vfs: Rename fsync_super() to sync_filesystem() " Jan Kara
2009-04-27 14:43 ` [PATCH 7/8] quota: cleanup dquota sync functions " Jan Kara
2009-04-27 14:43 ` [PATCH 8/8] quota: Introduce writeout_quota_sb() " Jan Kara
2009-04-27 17:36 ` [PATCH 0/8] Sync fixes and cleanups " Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090427123825.d24dbbbc.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.