4 ms·
That's gotta be the weasel-wordiest straight talk I've seen in a wee while. Here's a fact: the upstream's official statement is that RAID 1 isn't production-re
by rodgerd 9y ago
That's gotta be the weasel-wordiest straight talk I've seen in a wee while.
Here's a fact: the upstream's official statement is that RAID 1 isn't production-ready.
- cyphar 9y agoThat'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 https://btrfs.wiki.kernel.org/index.php/RAID56 [2]: https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mul... [3]: https://btrfs.wiki.kernel.org/index.php/Gotchas https://btrfs.wiki.kernel.org/index.php/Gotchas
- rodgerd 9y agohttps://btrfs.wiki.kernel.org/index.php/Status 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.
- colde 9y agoIn 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"
- danparsonson 9y agoCall 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".
- wtallis 9y agoAs 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.
- lightedman 9y ago"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.
- wtallis 9y ago> 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.
- sliken 9y agoSeems insane, after all not all reboots are voluntary.
- wtallis 9y ago"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.
- wtallis 9y ago> "Here's a fact: the upstream's official statement is that RAID 1 isn't production-ready." That doesn't seem to match anything I've seen. The btrfs status page classifies RAID1 and RAID10 features as "mostly OK". The one and only documented caveat is that when a disk in a RAID1 fails, you should mount the filesystem as read-only until you are ready to fix the problem by either replacing the failed disk or converting to a non-RAID profile. There's a real bug underlying this limitation, but the only way to encounter this bug is to be quite cavalier about how you handle a degraded array, by doing something that you shouldn't expect to be safe.
- rodgerd 9y ago> but the only way to encounter this bug is to be quite cavalier about how you handle a degraded array, by doing something that you shouldn't expect to be safe. The way to encounter it is to mount the array a second time. That's hardly "cavalier handling". A decade in, and RAID 1 doesn't work right. Saying this clearly offends the feels here at HN, but it's a fact.
- wtallis 9y ago> The way to encounter it is to mount the array a second time. That's hardly "cavalier handling". `mount` is not the same as `mount -o degraded,rw`. The latter should raise the eyebrows of anyone paying attention to what they're typing. Odds are that you'll have to consult the docs to even find these mount options, because it doesn't happen automatically. This is where any careful, sane user who's concerned about their data would spend a few more minutes thinking through their entire recovery procedure. There's one corner case to RAID1 recovery where the current tooling does not fully prevent a careless user from putting the FS in a bad state. This is not the same as "RAID1 doesn't work right".
- mioelnir 9y agoI don't think a careful, sane user who's concerned about their data would be on btrfs in the first place.