Re: Data single *and* raid?

[Duncan <1i5t5.duncan@cox.net>]

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.duncan@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