From: Eric Sandeen <sandeen@sandeen.net>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Eric Sandeen <esandeen@redhat.com>, Jan Kara <jack@suse.cz>,
Dave Jones <davej@redhat.com>, Andrew Morton <akpm@osdl.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.18 ext3 panic.
Date: Tue, 10 Oct 2006 20:43:35 -0500 [thread overview]
Message-ID: <452C4C47.2000107@sandeen.net> (raw)
In-Reply-To: <1160519106.28299.4.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty wrote:
> On Tue, 2006-10-10 at 17:03 -0500, Eric Sandeen wrote:
>> Jan Kara wrote:
>>
>>> I think it's really the 1KB block size that makes it happen.
>>> I've looked at journal_dirty_data() code and I think the following can
>>> happen:
>>> sync() eventually ends up in journal_dirty_data(bh) as Eric writes.
>>> There is finds dirty buffer attached to the comitting transaction. So it drops
>>> all locks and calls sync_dirty_buffer(bh).
>>> Now in other process, file is truncated so that 'bh' gets just after EOF.
>>> As we have 1kb buffers, it can happen that bh is in the partially
>>> truncated page. Buffer is marked unmapped and clean. But in a moment the page
>>> is marked dirty and msync() is called. That eventually calls
>>> set_page_dirty() and all buffers in the page are marked dirty.
>>> The first process now wakes up, locks the buffer, clears the dirty bit
>>> and does submit_bh() - Oops.
>> Hm, just FWIW I have a couple traces* of the buffer getting unmapped
>> -before- journal_submit_data_buffers ever even finds it...
>>
>> journal_submit_data_buffers():[fs/jbd/commit.c:242] needs writeout,
>> adding to array pid 1836
>> b_state:0x114025 b_jlist:BJ_SyncData cpu:0 b_count:2 b_blocknr:27130
>> b_jbd:1 b_frozen_data:0000000000000000
>> b_committed_data:0000000000000000
>> b_transaction:1 b_next_transaction:0 b_cp_transaction:0
>> b_trans_is_running:0
>> b_trans_is_comitting:1 b_jcount:0 pg_dirty:0
>>
>> so it's already unmapped at this point. Could
>> journal_submit_data_buffers benefit from some buffer_mapped checks? Or
>> is that just a bandaid too late...
>
> Hmm..
>
> b_state: 0x114025
> ^
> means BH_Mapped. Isn't it ?
Whoops, I pasted in the wrong one, I guess, from earlier in the trace. Here are
the ones I was looking at:
journal_submit_data_buffers():[fs/jbd/commit.c:242] needs writeout, adding to
array pid 1690
b_state:0x104005 b_jlist:BJ_SyncData cpu:0 b_count:2 b_blocknr:30045
b_jbd:1 b_frozen_data:0000000000000000 b_committed_data:0000000000000000
b_transaction:1 b_next_transaction:0 b_cp_transaction:0 b_trans_is_running:0
b_trans_is_comitting:1 b_jcount:0 pg_dirty:1
and
journal_submit_data_buffers():[fs/jbd/commit.c:242] needs writeout, adding to
array pid 1836
b_state:0x114005 b_jlist:BJ_SyncData cpu:1 b_count:2 b_blocknr:27130
b_jbd:1 b_frozen_data:0000000000000000 b_committed_data:0000000000000000
b_transaction:1 b_next_transaction:0 b_cp_transaction:0 b_trans_is_running:0
b_trans_is_comitting:1 b_jcount:0 pg_dirty:1
-Eric
next prev parent reply other threads:[~2006-10-11 1:43 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-02 19:47 2.6.18 ext3 panic Dave Jones
2006-10-03 5:22 ` Dave Jones
2006-10-03 5:43 ` Eric Sandeen
2006-10-03 6:19 ` Andrew Morton
2006-10-03 6:40 ` Dave Jones
2006-10-03 16:45 ` Dave Jones
2006-10-09 19:46 ` Eric Sandeen
2006-10-09 19:59 ` Eric Sandeen
2006-10-09 21:59 ` Badari Pulavarty
2006-10-09 22:50 ` Dave Jones
2006-10-10 14:11 ` Jan Kara
2006-10-10 18:42 ` Andrew Morton
2006-10-10 22:03 ` Eric Sandeen
2006-10-10 22:25 ` Badari Pulavarty
2006-10-11 1:43 ` Eric Sandeen [this message]
2006-10-11 10:33 ` Jan Kara
2006-10-11 13:44 ` Eric Sandeen
2006-10-11 14:22 ` Jan Kara
2006-10-11 17:54 ` Badari Pulavarty
2006-10-12 2:36 ` Eric Sandeen
2006-10-12 4:34 ` John Wendel
2006-10-12 6:57 ` Jan-Benedict Glaw
2006-10-12 12:28 ` Jan Kara
2006-10-12 13:20 ` Eric Sandeen
2006-10-12 16:40 ` Andrew Morton
2006-10-12 16:44 ` Eric Sandeen
2006-10-12 20:07 ` Eric Sandeen
2006-10-12 21:55 ` Badari Pulavarty
2006-10-12 21:57 ` Eric Sandeen
2006-10-12 22:34 ` Badari Pulavarty
2006-10-13 7:56 ` Jan Kara
2006-10-13 16:08 ` Eric Sandeen
2006-10-16 16:54 ` Jan Kara
2006-10-16 16:56 ` Eric Sandeen
2006-10-09 22:40 ` Jan-Benedict Glaw
2006-10-10 13:16 ` Jan Kara
2006-10-10 16:39 ` Jan-Benedict Glaw
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=452C4C47.2000107@sandeen.net \
--to=sandeen@sandeen.net \
--cc=akpm@osdl.org \
--cc=davej@redhat.com \
--cc=esandeen@redhat.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.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.