From: Eric Sandeen <sandeen@redhat.com>
To: Arthur Jones <ajones@riverbed.com>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"sct@redhat.com" <sct@redhat.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ext3: wait on all pending commits in ext3_sync_fs
Date: Mon, 03 Nov 2008 13:59:50 -0600 [thread overview]
Message-ID: <490F5836.5030302@redhat.com> (raw)
In-Reply-To: <20081103184426.GA31894@ajones-laptop.nbttech.com>
Arthur Jones wrote:
> Hi Eric, This patch fixes the problem for me, and
> seems to put the buffers on the dirty list at the
> place where they are put on the list during the working
> case. Despite having rooted around in the innards of
> ext3 for the last few days, I cannot say that I have
> any sense of whether this patch will cause problems
> elsewhere or even if this is the best place to
> intercede.
>
> I post the complete patch not because I think it
> should be committed as is, but rather to try
> to explain the logic that brought it about. At the
> very least, this should be reviewed by the experts
> here to make sure there is no collateral damage.
>
> Arthur
Seems like the right approach; I too was thinking that the problem was
we just weren't either kicking off, or waiting for, the log commit at
unmount time.
I've had to step away from this problem for a couple days but will
eyeball this soon, it seems like the right root cause & general approach
to a fix, to me.
Thanks!
-Eric
> -------------------
> In ext3_sync_fs, we only wait for a commit to
> finish if we started it, but there may be one
> already in progress which will not be synced.
>
> In the case of a data=ordered umount with pending long
> symlinks which are delayed due to a long list
> of other I/O on the backing block device, this
> causes the buffer associated with the long symlinks
> to not be moved to the inode dirty list in the second
> phase of fsync_super. Then, before they can be dirtied
> again, kjournald exits, seeing the UMOUNT flag and the
> dirty pages are never written to the backing block device,
> causing long symlink corruption and exposing new or
> previously freed block data to userspace.
>
> This can be reproduced with a script created
> by Eric Sandeen <sandeen@redhat.com>:
>
> #!/bin/bash
>
> umount /mnt/test2
> mount /dev/sdb4 /mnt/test2
> rm -f /mnt/test2/*
> dd if=/dev/zero of=/mnt/test2/bigfile bs=1M count=512
> touch
> /mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
> ln -s
> /mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
> /mnt/test2/link
> umount /mnt/test2
> mount /dev/sdb4 /mnt/test2
> ls /mnt/test2/
> umount /mnt/test2
>
> To ensure all commits are synced, we flush
> all journal commits now when sync_fs'ing ext3.
>
> Signed-off-by: Arthur Jones <ajones@riverbed.com>
> ---
> fs/ext3/super.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/fs/ext3/super.c b/fs/ext3/super.c
> index 18eaa78..053659a 100644
> --- a/fs/ext3/super.c
> +++ b/fs/ext3/super.c
> @@ -2392,7 +2392,13 @@ static int ext3_sync_fs(struct super_block *sb, int wait)
> if (journal_start_commit(EXT3_SB(sb)->s_journal, &target)) {
> if (wait)
> log_wait_commit(EXT3_SB(sb)->s_journal, target);
> - }
> + } else if (wait)
> + /*
> + * We may have a commit in progress, clear it out
> + * before we go on...
> + */
> + ext3_force_commit(sb);
> +
> return 0;
> }
>
prev parent reply other threads:[~2008-11-03 20:00 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 18:37 ext3: slow symlink corruption on umount Arthur Jones
2008-10-27 16:54 ` Arthur Jones
2008-10-29 19:54 ` Arthur Jones
2008-10-29 20:36 ` Eric Sandeen
2008-10-29 21:09 ` Theodore Tso
2008-10-30 13:38 ` Eric Sandeen
2008-10-30 13:55 ` Arthur Jones
2008-10-31 9:47 ` Nick Piggin
2008-10-30 17:40 ` Arthur Jones
2008-10-30 18:03 ` Eric Sandeen
2008-10-30 21:34 ` Arthur Jones
2008-10-31 17:24 ` Arthur Jones
2008-10-31 18:37 ` Eric Sandeen
2008-10-30 18:32 ` Arthur Jones
2008-11-03 18:44 ` [PATCH] ext3: wait on all pending commits in ext3_sync_fs Arthur Jones
2008-11-03 19:33 ` Andrew Morton
2008-11-03 20:14 ` Arthur Jones
2008-11-03 20:37 ` Andrew Morton
2008-11-03 20:58 ` Arthur Jones
2008-11-03 21:13 ` Andrew Morton
2008-11-03 21:19 ` Theodore Tso
2008-11-03 21:27 ` Andrew Morton
2008-11-03 21:48 ` Theodore Tso
2008-11-03 22:01 ` Theodore Tso
2008-11-03 22:18 ` Arthur Jones
2008-11-03 22:27 ` Andrew Morton
2008-11-03 22:55 ` Theodore Tso
2008-11-03 23:01 ` Arthur Jones
2008-11-03 23:12 ` Theodore Tso
2008-11-04 16:26 ` Arthur Jones
2008-11-03 21:48 ` Arthur Jones
2008-11-03 22:47 ` Theodore Tso
2008-12-18 23:17 ` Jan Kara
2008-12-18 23:37 ` Eric Sandeen
2008-12-19 0:27 ` Jan Kara
2008-12-19 1:34 ` Eric Sandeen
2008-12-22 19:15 ` Ric Wheeler
2008-12-22 22:57 ` Andreas Dilger
2008-12-23 0:09 ` Ric Wheeler
2008-12-23 15:56 ` Eric Sandeen
2009-01-12 22:28 ` Jan Kara
2009-01-13 17:21 ` Eric Sandeen
2009-01-13 22:14 ` Eric Sandeen
2009-01-14 4:24 ` Theodore Tso
2009-01-14 17:26 ` Eric Sandeen
2009-01-14 17:27 ` Jan Kara
2009-01-29 18:27 ` Mike Snitzer
2009-01-29 20:05 ` Eric Sandeen
2008-11-03 19:59 ` Eric Sandeen [this message]
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=490F5836.5030302@redhat.com \
--to=sandeen@redhat.com \
--cc=ajones@riverbed.com \
--cc=akpm@linux-foundation.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).