linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: George Barnett <gbarnett@atlassian.com>,
	linux-ext4@vger.kernel.org,
	Debian kernel maintainers <debian-kernel@lists.debian.org>
Subject: Re: [PATCH] ext4/jbd2: don't wait (forever) for stale tid caused by wraparound
Date: Mon, 18 Mar 2013 10:31:56 -0400	[thread overview]
Message-ID: <20130318143156.GA14430@thunk.org> (raw)
In-Reply-To: <1363582395.3937.319.camel@deadeye.wl.decadent.org.uk>

On Mon, Mar 18, 2013 at 04:53:15AM +0000, Ben Hutchings wrote:
> 
> We need you to verify that this fix works first.  If it does, it should
> get included in the various 3.x.y stable branches and in Debian kernel
> packages.

I suspect it will be hard for George to verify this, since it requires
a tid wrap, which by definition takes a long time.

Also, this will probably not hit the stable kernels until after the
next merge window, since it's already post -rc3 and I really want to
make sure this gets a lot of testing and review.

I'll also note that I managed to trigger a BUG when incrementing by a
factor of (1 << 24), but we don't see a BUG_ON when incrementing by
((1 << 24) + 1).  (Neither of these testing changes were in the patch
that I sent out; so the patch is "safe" in that I very much doubt it
will make things worse --- those changes were to stress test the patch
so that I wouldn't have to wait several months until the tid wrapped
to test whether we had finally fixed all of the potential problems.)
So there is something we probably do want to look at a bit more
closely before we formally push this fix into mainline.

As far as the Debian servers are concerned, I'm pretty sure the patch
should be safe in that it won't make things worse than they were
before --- however, if you are looking for the lowest risk approach,
it's probably better to simply schedule downtime every few months and
force a reboot at a time that is minimizes developer inconvenience.
You can use "dumpe2fs -h /dev/XXX" to get the current sequence number
of the journal, if you measure the sequence number separated by 24 or
48 hours, you should be able to calculate when the the sequence number
will have incremented by 2**31, and thus calculate the frequency of
scheduled reboots for your workload.

Regards,

						- Ted

  reply	other threads:[~2013-03-18 14:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <B2EC601CDDA242189A46599B31EA6AD3@atlassian.com>
2013-03-16  5:34 ` jbd2 tid wrap seen on NFS server Ben Hutchings
2013-03-18  2:54   ` [PATCH] ext4/jbd2: don't wait (forever) for stale tid caused by wraparound Theodore Ts'o
2013-03-18  4:24     ` George Barnett
2013-03-18  4:53       ` Ben Hutchings
2013-03-18 14:31         ` Theodore Ts'o [this message]
2013-03-18 14:34           ` Theodore Ts'o
2013-03-21 20:46     ` Jan Kara
2013-03-21 21:09       ` Theodore Ts'o
2013-03-21 22:41         ` 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=20130318143156.GA14430@thunk.org \
    --to=tytso@mit.edu \
    --cc=ben@decadent.org.uk \
    --cc=debian-kernel@lists.debian.org \
    --cc=gbarnett@atlassian.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).