From: Josef Bacik <josef@redhat.com>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Cc: Jan Kara <jack@suse.cz>
Subject: Can a metadata buffer end up in journal_unmap_buffer?
Date: Thu, 11 Aug 2011 09:32:22 -0400 [thread overview]
Message-ID: <4E43D9E6.9030503@redhat.com> (raw)
Hello,
I have this weird bug that has been plaguing me for a while where
t_outstanding_credits will end up less than t_nr_buffers. I have done
all sorts of things to try and catch when it happens but nothing seems
to catch it. At some point I had thought that we were screwing up in
journal_unmap_buffer. If a buffer is not on a transaction but is still
a part of a checkpoint we will do a journal_file_buffer() onto the
current running transaction's forget list. The thing is we can still
have b_modified set since we only clear it on
do_get_write_access/journal_get_create_access if it isn't a part of the
transaction yet. So if we do the journal_file_buffer() before anybody
calls do_get_write_access/journal_get_create_access we will short
circuit these checks and b_modified will never be cleared and so when we
do journal_dirty_metadata we won't account for the new buffer and it
will end up inc'ing t_nr_buffers but not t_outstanding_credits.
I had thought this was the problem before and put in a jh->b_modified =
0 in __dispose_buffer, but apparently the problem still happened. But
that support person/customer were not entirely reliable so I'm back to
thinking this is what happened and they just didn't run with my patch.
The problem is I don't think we can call journal_unmap_buffer() on just
a normal metadata block (that is with data=ordered), it only gets called
by ext3_invalidatepage() which is only called on pages on the inodes
address space, so not metadata. However, Jan had a patch to delay the
free'ing of buffers for orphan reasons, with commit
86963918965eb8fe0c8ae009e7c1b4c630f533d5
which makes it seem like metadata can come through
journal_unmap_buffer()? Does anybody know for sure one way or the
other? And if you happen to have a theory on the actual problem itself
I would _love_ to hear it :). Thanks,
Josef
next reply other threads:[~2011-08-11 13:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-11 13:32 Josef Bacik [this message]
2011-08-11 15:28 ` Can a metadata buffer end up in journal_unmap_buffer? Jan Kara
2011-08-11 16:16 ` Josef Bacik
2011-08-11 16:21 ` Josef Bacik
2011-08-11 20:38 ` Josef Bacik
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=4E43D9E6.9030503@redhat.com \
--to=josef@redhat.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
/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.