Chris Murphy posted on Sat, 01 Aug 2015 19:14:13 -0600 as excerpted: > On Sat, Aug 1, 2015 at 6:27 PM, Duncan <1i5t5.dun...@cox.net> wrote: > >> 1) If this fs was created with btrfs-progs v4.1.1, get what you need to >> retrieve off of it immediately, then blow it away and start over, as >> the thing isn't stable and all data is at risk. > > Agreed. But I'd go so far as to say at this point it looks like it's > wedged itself into a kind of self-induced faux-ENOSPC state because > there isn't room to allocate more raid5 chunks. So, I think it's stuck > in any case.
Well, yes and no. If it was setup with progs v4.1.1, save what you can and blow it away as it's not stable enough to try anything else. If it was setup with something earlier (not sure about 4.1.0, was it affected? but 4.0.x and earlier should be fine for setup), however, once on a new kernel the usual ENOSPC workarounds can be given a try. That would include a first balance start -dusage=0 -musage=0, and if that didn't free up at least a gig on a second device, I'd try the old add-a- device trick and see what happens. (A few GiB thumb drive should work in a pinch, or even a ramdrive if you're willing to risk loss in the event of a crash vaporizing everything in memory including the ramdrive.) After all, even if he didn't know the risk of the still very new raid56 mode before, he does after reading my earlier message, and anything of value should be backed up before he attempts anything, so at that point, there's nothing to lose and it's upto him whether he wants to simply blow away the current setup and start over with either raid1 or (with another device) raid10, avoiding the current risk of raid56, or blow away and start over with raid56 again, knowing the risks now, or try to recover what's there, viewing it not as the easiest way but as practice in disaster recovery, again, with anything of value backed up so there's nothing to lose besides the time of fiddling with it and ending up having to blow away and restart from backups anyway, regardless of how it goes. > It'd be great to reproduce this with a current kernel and see if it's > still happening. Absolutely. Tho at this point I believe the chances are pretty good it's simply either that bad 4.1.1 mkfs.btrfs, or an older pre-full-raid56-support kernel that didn't handle balance to raid56 so well, yet, and that on the latest userspace and kernel the problem shouldn't reoccur. But it'd be nice to *KNOW* that, by trying to reproduce, absolutely. He may well have stumbled upon yet another confirmation of my recommendation to wait on raid56 unless you're deliberately testing it, and confirmation thereof would be halfway to getting it fixed, so those who /do/ choose to wait won't be dealing with it. =:^) -- 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" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
