Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: raid10 drive replacement
Date: Sat, 18 Oct 2014 23:27:52 +0000 (UTC)	[thread overview]
Message-ID: <pan$3bb44$7642c5c4$22d7904d$2c7ad586@cox.net> (raw)
In-Reply-To: daf1096c58d3dd54392809f7d3f89e4d@sonic.net

Suman Chakravartula posted on Fri, 17 Oct 2014 19:02:49 -0700 as
excerpted:


> On 2014-10-17 18:47, Vincent. wrote:
>> Hi !
>> 
>> I have a faulty drive in my raid10 and want it to be replaced. Working
>> drive are xvd[bef] and replacement drive is xvdc.
>> 
> This is something I ran into the other day. Key difference is that I was
> running 3.17.1 kernel and 3.16 btrfs-progs
> 
>> When I mount my drive in RW:
>> #mount -odegraded /dev/xvdb /tank
>> [ 6219.703606] Btrfs: too many missing devices, writeable mount
>> is not allowed
>> 
>> 
> In my case, I was able to rw mount. May be update btrfs-progs and retry?
>> 
> Because my mount was rw, replace worked.
> 
>> FYI I'm on ubuntu 14.04 with btrfs 3.12

I'd suggest updating both btrfs-progs (as Suman suggested) and the kernel 
(the version of which you don't mention).

There was a period when btrfs was too strict in what it would allow to 
mount writable, thus not allowing a device replace to fix the problem.  
It would appear ubuntu 14.4's versions fell in that period.

For kernel, given some recent bugs, you want the latest stable 3.16, 
definitely > 3.16.2 as that contained a vital btrfs bugfix.  Current 3.17 
stable has a different bug that didn't affect 3.16, patch pending but not 
in 3.17, or in 3.18-rc yet, but 3.16.4 (I believe the latest) should be 
good.  You can also try the latest long-term-stable 3.14.x as it's pretty 
stable btrfs-wise, but 3.14 might have still been in the can't-mount-
writable period and I'm not sure they backported that fix to stable-
series.  But 3.16.4+ should be great.

Because btrfs is evolving so fast, in general you'll want to run a 
current kernel and keep up with the list to know about any current bugs 
(like the one currently affecting 3.17 and the 3.18-rcs, and the earlier 
one affecting the entire 3.15 series and 3.16 before 3.16.2).  Most 
distros run somewhat outdated kernels so sticking to a distro kernel 
doesn't always work so well.

btrfs-progs userspace isn't quite so vital to keep current as the kernel, 
but you still want to keep at least reasonably current.  3.12 is getting 
a bit long in the tooth, now, and I'd recommend at least 3.14.2, with 
3.16.1 preferred.  (A 3.17 is in rc ATM but not yet released.)

And (you may not need this but we get people all the time for whom it's a 
bit late so it's worth repeating) of course, because btrfs /is/ evolving 
so fast and isn't yet completely stable, the general rule that if you 
value it you have backups for it that applies even to mature and stable 
filesystems such as ext3 and ext4, applies even more to btrfs.   If 
something goes wrong and you don't have a backup, no matter HOW much you /
claim/ to value that data in hindsight, your actions say you simply 
didn't value it enough to ensure yourself against such possibilities by 
keeping backups, which means you by your actions you considered it throw-
away data if something /did/ go wrong.  Also, be aware that a backup 
that's not tested can't be considered a backup at all, because you don't 
know for sure that you can recover from it.  And RAID isn't a substitute 
for backups.

So if you value your data, have (tested) backups!  Not doing so simply 
means you don't value that data, no matter what you /claim/.

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


      parent reply	other threads:[~2014-10-18 23:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-18  1:47 raid10 drive replacement Vincent.
2014-10-18  2:02 ` Suman Chakravartula
2014-10-18  4:37   ` Anand Jain
2014-10-18 23:12     ` Vincent.
2014-10-20  1:33       ` Anand Jain
2014-10-18 23:27   ` Duncan [this message]

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$3bb44$7642c5c4$22d7904d$2c7ad586@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