News for hackers. Stuff that matters.
Re:A straight talk about btrfs by cyphar on Thursday August 24, 2017 @02:50AM (#15088149)
That's not accurate. Upstream btrfs doesn't support RAID56[1]. However, neither their multiple devices page[2] nor their gotchas page[3] mention that raid0, raid1 or raid10 are not recommended for production. Do you have a citation for your claim?

[1]: https://btrfs.wiki.kernel.org/index.php/RAID56 [2]: https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mul... [3]: https://btrfs.wiki.kernel.org/index.php/Gotchas

Re:A straight talk about btrfs by rodgerd on Thursday August 24, 2017 @04:14AM (#15088429)
https://btrfs.wiki.kernel.org/index.php/Status

"RAID1 mostly OK Can get stuck in irreversible read-only mode if only one device is present."

Which is an especially toxic combination with things like:

"Device replace mostly OK"

It's 30 seconds to find the status page if you're actually trying.

Re:A straight talk about btrfs by colde on Thursday August 24, 2017 @05:26AM (#15088697)
In that same page however, they also define "mostly OK" as: > mostly OK: safe for general use, there are some known problems

This would seem to suggest they are saying it is okay for production use. Otherwise, what do they mean by "safe for general use"

Re:A straight talk about btrfs by danparsonson on Thursday August 24, 2017 @07:36AM (#15089218)
Call me conservative but "Can get stuck in irreversible read-only mode if only one device is present" doesn't equate to "okay for production use" when I'm considering deploying a filesystem; likewise "device replace" being "mostly OK".
Re:A straight talk about btrfs by wtallis on Thursday August 24, 2017 @07:52AM (#15089294)
As I've explained elsewhere, that "irreversible read-only mode" is well documented and completely avoidable, and even if you do trigger it a one-line kernel patch will bypass the overzealous safety check and allow you to complete the recovery process. If you're actually using something in production, you should probably RTFM so you can avoid shooting yourself in the foot.
Re:A straight talk about btrfs by lightedman on Thursday August 24, 2017 @08:10AM (#15089388)
"As I've explained elsewhere, that "irreversible read-only mode" is well documented and completely avoidable"

And yet it hasn't been fixed despite being well-known? That tells me to stay away from it more than anything else.

"even if you do trigger it a one-line kernel patch will bypass the overzealous safety check"

I shouldn't need to hackjob my kernel to make a single individual lone drive work. If you can't work with a single hard drive, you have no business trying to work with multiple hard drives.

Re:A straight talk about btrfs by wtallis on Thursday August 24, 2017 @10:06AM (#15090199)
> I shouldn't need to hackjob my kernel to make a single individual lone drive work.

You don't. You only need the hack if you do a bad job of cleaning up after the loss of the other half of your two-drive mirror. ZFS won't let you transition in-place from RAID to non-RAID at all. Btrfs just requires that you not reboot in the middle of that migration.

Re:A straight talk about btrfs by sliken on Thursday August 24, 2017 @02:18PM (#15092597)
Seems insane, after all not all reboots are voluntary.
Re:A straight talk about btrfs by wtallis on Thursday August 24, 2017 @06:21PM (#15094568)
"Insane" is pretty strong for a temporary limitation that is just as severe with traditional RAID arrays. A sudden power failure or any other hardware problem cropping up during an array rebuild is a nightmare scenario.
Re:A straight talk about btrfs by cyphar on Thursday August 24, 2017 @11:40PM (#15095938)
It should be noted that md-raid does handle that scenario. I agree with you that the characterisation of this present limitation in btrfs is quite unfair, but not all RAID systems are susceptible to that problem.