From: Jan Kara <jack@suse.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
Jan Kara <jack@suse.cz>, Dave Wysochanski <dwysocha@redhat.com>
Subject: Re: [PATCH RFC] jbd: don't wake kjournald unnecessarily
Date: Wed, 19 Dec 2012 03:05:26 +0100 [thread overview]
Message-ID: <20121219020526.GG5987@quack.suse.cz> (raw)
In-Reply-To: <20121219012710.GF5987@quack.suse.cz>
On Wed 19-12-12 02:27:10, Jan Kara wrote:
> > With a u8 tid_t, the "else" clause from commit d9b0193 fires
> > frequently; I really think the underlying problem is that tid_geq()
> > etc does not properly handle wraparounds - if, say, target is 255
> > and j_commit_request is 0, we don't know if j_commit_request
> > is 255 tids behind, or 1 tid ahead. I have to think about that
> > some more, unless it's obvious to someone else.
> Well, there's no way to handle wraps better AFAICT. Tids eventually wrap
> and if someone has stored away tid of a transaction he wants committed and
> keeps it for a long time before using it, it can end up being anywhere
> before / after current j_commit_request. The hope was that it takes long
> enough to wrap around 32-bit tids. If this happens often in practice we may
> have to switch to 64-bit tids (in memory, on disk 32-bit tids are enough
> because of limited journal size).
>
> > FWIW, some people have indeed seen that else clause fire upstream,
> > both in the case where j_commit_request is > 2^31 and the
> > target is 0.
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=46031
> > http://forums.debian.net/viewtopic.php?f=5&t=80741
> This is actually curious. The fact that i_datasync_tid was 0 means that
> either journal was not initialized during ext3_iget() or j_commit_sequence
> was 0 during ext3_iget() - note that j_commit_sequence is initialized to
> j_transaction_sequence in journal_reset()... Hum, but in a case when
> ext3_load_journal() calls journal_wipe() and that finds j_tail != 0, we
> call journal_skip_recovery(). That ends up setting j_transaction_sequence
> to the last transaction in the log but j_commit_sequence is left at 0.
> I see that explains how we could hit the warning. I think we should
> initialize j_commit_sequence properly also when skipping recovery and that
> will solve the problem.
Bah, I was wrong here. I misread ext3_journal_load(). We call
journal_load() after journal_wipe() and so j_transaction_sequence and
j_commit_sequence() are set properly... But then I don't see how
i_datasync_tid was zero (modulo the very unlikely event we happened to load
the inode just after wrapping tids).
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2012-12-19 2:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-18 17:03 [PATCH RFC] jbd: don't wake kjournald unnecessarily Eric Sandeen
2012-12-19 1:27 ` Jan Kara
2012-12-19 2:05 ` Jan Kara [this message]
2012-12-19 3:08 ` Eric Sandeen
2012-12-19 8:13 ` Jan Kara
2012-12-19 15:37 ` Theodore Ts'o
2012-12-19 17:14 ` Jan Kara
2012-12-19 20:27 ` Theodore Ts'o
2012-12-19 21:19 ` Eric Sandeen
2012-12-21 17:01 ` Eric Sandeen
2012-12-21 17:46 ` Theodore Ts'o
2013-01-08 19:19 ` Eric Sandeen
2013-01-11 16:42 ` Eric Sandeen
2013-01-11 19:03 ` Jan Kara
2013-01-11 19:06 ` Eric Sandeen
2012-12-19 15:46 ` Eric Sandeen
2012-12-19 17:11 ` Jan Kara
2012-12-19 2:36 ` Eric Sandeen
2012-12-19 2:59 ` [PATCH] jbd2: " Eric Sandeen
2012-12-19 8:09 ` Jan Kara
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=20121219020526.GG5987@quack.suse.cz \
--to=jack@suse.cz \
--cc=dwysocha@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@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.