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: ext3: slow symlink corruption on umount...
Date: Fri, 31 Oct 2008 13:37:24 -0500 [thread overview]
Message-ID: <490B5064.2000506@redhat.com> (raw)
In-Reply-To: <20081031172446.GC8333@ajones-laptop.nbttech.com>
Arthur Jones wrote:
> On Thu, Oct 30, 2008 at 02:34:00PM -0700, Arthur Jones wrote:
>> Hi Eric, ...
>>
>> On Thu, Oct 30, 2008 at 11:03:49AM -0700, Eric Sandeen wrote:
>>> [...]
>>> Something is definitely racy here; in my simple testcase I get failures
>>> maybe 30-50% of the time...
>> Some more info: in the working case, the inodes are put
>> back on sb->s_dirty at then next ext3_sync_fs() call:
>>
>> __fsync_super -> DQUOT_SYNC -> ext3_sync_fs -> log_wait_commit
>>
>> In the failing case, journal_start_commit returns 0 in ext_sync_fs
>> and the inodes disappear into never-never land...
>
> More details, these are dumps at __log_start_commit in the
> call chain described above, the first column is the failing
> case, the next column is working case, t_expires is the delta
> from the time the dump was taken:
>
> journal->j_flags 0x10 0x10
> journal->j_tail_sequence 515 519
> journal->j_transaction_sequence 517 522
> journal->j_commit_sequence 514 519
> journal->j_commit_request 516 520
>
> journal->j_running_transaction->t_tid 516 521
> journal->j_running_transaction->t_state 0 0
> journal->j_running_transaction->t_updates 0 0
> journal->j_running_transaction->t_handle_count 27305 27344
> journal->j_running_transaction->t_expires -566 28
>
> Can you tell from this whether the transactions
> are messed up or whether we're just missing a
> wake_up? Any other info you'd like to see?
That's kind of along the lines of what I'm seeing; also, in particular,
I'm never seeing the buffer_head in question (the one for the block
which contains the slow link's data) transition from jbddirty to normal
BH_Dirty. I've had to take a break from this today, but will be back at
it a bit later... since I have a solid testcase I'm sure I'll get to the
bottom of it ... :) I'll probably hook up akpm's buffer tracing
infrastructure, just need to find a decent thing to trigger on to dump
out the history.
-Eric
next prev parent reply other threads:[~2008-10-31 18:37 UTC|newest]
Thread overview: 53+ 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: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 [this message]
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: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:26 ` Eric Sandeen
2009-01-14 17:27 ` Jan Kara
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
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=490B5064.2000506@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 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.