Jan Voet <jan.voet <at> gmail.com> writes: > > Duncan <1i5t5.duncan <at> cox.net> writes: > > > FWIW, btrfs raid5 (and raid6, together called raid56 mode) is still > > extremely new, only normal runtime implemented as originally introduced, > > with complete repair from a device failure only completely implemented in > > kernel 3.19, and while in theory complete, that implementation is still > > very immature and poorly tested, and *WILL* have bugs, one of which you > > may very well have found. > > > > For in-production use, therefore, btrfs raid56 mode, while now at least > > in theory complete, is really too immature at this point to recommend. > > I'd recommend either btrfs raid1 or raid10 modes as more stable within > > btrfs at this point, tho by the end of this year or early next, I predict > > raid56 mode to have stabilized to about that of the rest of btrfs, which > > is to say, not entirely stable, but heading that way. > > > Looks like the the btrfs raid5 filesystem is back in working order. What actually happened was that on reboot of the server, the interrupted btrfs balance tried to resume each time, but wasn't capable of it due to an incorrect/invalid state. The amount of errors that were spawned by this made it very difficult to diagnose, as the kernel log got truncated very quickly. Doing a 'btrfs balance cancel' immediately after the array was mounted seems to have done the trick. A subsequent 'btrfs check' didn't show any errors at all and all the data seems to be there. :-) Kind regards, Jan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
