All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.