From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: 40TB volume taking over 16 hours to mount, any ideas?
Date: Sun, 10 Aug 2014 04:03:47 +0000 (UTC) [thread overview]
Message-ID: <pan$bda9a$bcfe7d3f$f7527ba5$c0b77ff1@cox.net> (raw)
In-Reply-To: 20140809182113.GI12778@merlins.org
Marc MERLIN posted on Sat, 09 Aug 2014 11:21:13 -0700 as excerpted:
> You could argue that since 3.16.0 does not have the recently found
> deadlock patch that's been plaging 15 and 16 (14 not as much for me),
> it's not usable for some (it ran about 1 day on my laptop before
> deadlocking, and maybe an hour at most on my server).
>
> I sure hope that deadlock patch is going to be added to the 3.16.x tree,
> I'm not super stocked with being stuck at 3.14.
Well, yes.
It'll almost certainly make it to the stable series including 3.16.x
shortly after it ends up in the 3.17 development tree. But the switch to
worker-threads was only with 3.15, so anything previous to that doesn't
need it (thus 3.14 working well for you, previous versions had other
bugs), and 3.15 isn't a long-term-stable and Greg KH already warned that
the just-Friday-released 3.15.9 is its penultimate release and people
should be thinking about switching to 3.16, so pre-3.15 the patch isn't
needed and whether it'll make it into 3.15.10, the last 3.15-series
release, is questionable at this point, so 3.17-development or presumably
3.16.1 or 3.16.2 looks to be the soonest it'll possibly happen for people
not willing to cherrypick the patch from the list as soon as posted.
FWIW, 3.15 (where I didn't have time to try the development series and
only upgraded about time it came out) and the 3.16 development series
including the 3.16.0 release have worked well enough for me, but my btrfs
are all on ssd, the ones I regularly mount all being raid1-pairs, and
apparently on my 6-core at least, the bug is hard enough to trigger on
ssd and I don't routinely push them hard enough to have seen it, thus
explaining why I've not had problems with 3.15 and the 3.16 series up
thru 3.16.0 release, beyond an instance that was either right about 3.15
release or in 3.14, and might have been a one-off as it certainly was for
me.
Tho while the problem has been pretty well traced so we know what it is,
I'm not sure that a full patch for it has yet been posted on the list,
has it? I think it was nailed down too late in the week to prepare and
pre-post test a patch before the weekend. So I'd expect to see the patch
on the list on Tuesday or so, just in time to make the last bit of the
3.17 commit window (tho it's a stable-candidate fix so could go in later
as well), but likely too late to make 3.15.10 and 3.16.1, so 3.17-rc1 or
3.16.2 it'll likely be.
--
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
next prev parent reply other threads:[~2014-08-10 4:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-08 21:35 40TB volume taking over 16 hours to mount, any ideas? Jose Ildefonso Camargo Tolosa
2014-08-09 3:38 ` Russell Coker
2014-08-09 14:32 ` Andy Smith
2014-08-09 14:58 ` Jose Ildefonso Camargo Tolosa
2014-08-09 16:06 ` Jose Ildefonso Camargo Tolosa
2014-08-09 17:01 ` Duncan
2014-08-09 18:21 ` Marc MERLIN
2014-08-10 4:03 ` Duncan [this message]
2014-08-10 12:43 ` Holger Hoffstätte
2014-08-10 14:39 ` Fixing the btrfs deadlocks Marc MERLIN
2014-08-10 15:42 ` Holger Hoffstätte
2014-08-10 16:36 ` Marc MERLIN
2014-08-09 18:38 ` 40TB volume taking over 16 hours to mount, any ideas? Jose Ildefonso Camargo Tolosa
2014-08-09 21:02 ` Jose Ildefonso Camargo Tolosa
2014-08-10 3:58 ` Jose Ildefonso Camargo Tolosa
2014-08-10 8:24 ` Duncan
2014-08-10 8:50 ` Timofey Titovets
2014-08-10 10:16 ` Duncan
2014-08-10 16:25 ` Chris Murphy
2014-08-11 21:33 ` Jose Ildefonso Camargo Tolosa
2014-08-12 4:15 ` Duncan
2014-08-12 14:24 ` Marc MERLIN
2014-08-13 2:02 ` Jose Ildefonso Camargo Tolosa
2014-08-10 4:21 ` Duncan
2014-08-10 4:57 ` Mitch Harder
2014-08-10 7:21 ` Duncan
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$bda9a$bcfe7d3f$f7527ba5$c0b77ff1@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).