linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: 3.11.5 kernel infinite loop
Date: Wed, 6 Nov 2013 12:37:32 +0000 (UTC)	[thread overview]
Message-ID: <pan$70f09$474e61ed$c27deec7$82b1529a@cox.net> (raw)
In-Reply-To: 201311061252.39398.russell@coker.com.au

Russell Coker posted on Wed, 06 Nov 2013 12:52:38 +1100 as excerpted:

> I have a system running the Debian package of 3.11.5 with an Amd Opteron
> 1212 processor (2*64bit cores), 8G of RAM, and an Intel 120G SSD for the
> root and home subvols.  It has a RAID-1 array of 2*3TB disks for bulk
> storage (movies etc) but that probably isn't relevant to this problem.
> 
> On the root filesystem I have cron jobs making daily snapshots of / and
> /home and additional snapshots of /home every 15 minutes.  At midnight a
> cron job removes older snapshots.  For the last 8 days the system has
> been reliably hanging at about 5 minutes after midnight and the subvol
> removal cron job is the only thing that has happened then.

I believe there's a btrfs-critical stable-series patch in 3.11.6, that 
you're probably missing with 3.11.5.  (There were unfortunately some 
crossed signals and the patch was skipped for a couple weeks after it 
should have gone in, but it's in now.)

Yes... Just checked the 3.11.6 changelog:

Josef Bacik (1):
      Btrfs: use right root when checking for hash collision


Note that there's another critical patch in-flight, patching a bug 
triggered by btrfs balance on filesystems with pre-allocated files (like 
systemd does with its journal and various torrent clients do with their 
downloads).  But this one is currently being held up because stable rules 
require it to be in current mainline first, and 3.12 is out, but the two-
week 3.13 commit window that would normally be open now is suspended for 
a week, as Linux is traveling without a reliable net connection.  So the 
patch can't hit mainline, and thus won't hit stable unless an exception 
is made, until after Linus' vacation, when the commit window opens and 
the patch is accepted.

See previous discussion here on this list for it, or simply don't do any 
balances if you're running systemd or with any other pre-allocated-file 
apps such as torrent clients running, until after you get that patch.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2013-11-06 12:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06  1:52 3.11.5 kernel infinite loop Russell Coker
2013-11-06 12:37 ` Duncan [this message]
2013-11-09  1:22   ` Chris Samuel

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='pan$70f09$474e61ed$c27deec7$82b1529a@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@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).