On Thu, Feb 02, 2017 at 07:49:50AM -0500, Austin S. Hemmelgarn wrote: > This is a severe bug that makes a not all that uncommon (albeit bad) use > case fail completely. The fix had no dependencies itself and
I don't see what's bad in mounting a RAID degraded. Yeah, it provides no redundancy but that's no worse than using a single disk from the start. And most people not doing storage/server farm don't have a stack of spare disks at hand, so getting a replacement might take a while. Being able to continue to run when a disk fails is the whole point of RAID -- despite what some folks think, RAIDs are not for backups but for uptime. And if your uptime goes to hell because the moment a disk fails you need to drop everything and replace the disk immediately, why would you use RAID? > > I /thought/ the immediate benefit was obvious enough that it > > would be mainline-merged by now, not hoovered-up into some long-term > > project with no real hint as to /when/ it might be merged. Oh, well... > I think (although I'm not sure about it) that this: > http://www.spinics.net/lists/linux-btrfs/msg47283.html > is the first posting of the patch series. Is there a more recent version somewhere? Mechanically rebasing+resolving conflicts doesn't work, I'd need to do a more involved refresh, which would be a waste of time if it's already done by someone with an actual clue about this code. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
