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: 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


  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).