Any idea ?Thanks !--fensoft--To unsubscribe from this list: send the line "unsubscribe linux-btrfs" inthe body of a message to ***@vger.kernel.orgMore majordomo info at http://vger.kernel.org/majordomo-info.html

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 tomount 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.17stable has a different bug that didn't affect 3.16, patch pending but notin 3.17, or in 3.18-rc yet, but 3.16.4 (I believe the latest) should begood. You can also try the latest long-term-stable 3.14.x as it's prettystable 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 acurrent 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 earlierone affecting the entire 3.15 series and 3.16 before 3.16.2). Mostdistros run somewhat outdated kernels so sticking to a distro kerneldoesn'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 gettinga bit long in the tooth, now, and I'd recommend at least 3.14.2, with3.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 abit late so it's worth repeating) of course, because btrfs /is/ evolvingso fast and isn't yet completely stable, the general rule that if youvalue it you have backups for it that applies even to mature and stablefilesystems such as ext3 and ext4, applies even more to btrfs. Ifsomething 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 simplydidn't value it enough to ensure yourself against such possibilities bykeeping backups, which means you by your actions you considered it throw-away data if something /did/ go wrong. Also, be aware that a backupthat's not tested can't be considered a backup at all, because you don'tknow for sure that you can recover from it. And RAID isn't a substitutefor backups.

So if you value your data, have (tested) backups! Not doing so simplymeans 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

--To unsubscribe from this list: send the line "unsubscribe linux-btrfs" inthe body of a message to ***@vger.kernel.orgMore majordomo info at http://vger.kernel.org/majordomo-info.html