Hi.

I rebooted the server after doing some dust clearing, and upon reboot, the cable of one of the two cache drives was loose, and the drive wasn't connecting.

 

I wiggled the thing back in place, and since then, here is where I am. A >RAID ONE< BTRFS pool sharted itself for a disconnected drive.

 

 

And I thought it would somehow protect data a bit? Apparently not. Might actually cause me to loose some irreplaceable one.

 

Here with the array started normally

 

And in maintenance mode:

 

It used to be absolutely error-less, but... hey, I tried a check without the readonly option, I might should have avoided doing that.

 

As for btrfs fi show, it seems like that thing forgot what is the second device in the cache pool.

Because yes, both SSDs in the cache pool are the original SSDs of the cache pool, and in the right order.

 

Wanting to recover the fail hits a road block also

 

I always used XFS for my array and have been happy with it... when I added my first cache drive, I saw btrfs and I was "oh well..."

That's a nice first experience with btrfs for me.

 

 

procyon-diagnostics-20200117-1234.zip

 

 

 

 

Edited January 17, 20206 yr by Keexrean

Jan 17 12:24:10 Procyon kernel: BTRFS warning (device sde1): chunk 536020516864 missing 1 devices, max tolerance is 0 for writeable mount

Pool wasn't redundant, likely because of this bug.

 

8 minutes ago, Keexrean said:

I tried a check without the readonly option, I might should have avoided doing that.

Yes, that's a last resort, you can try these options though not sure how good they will work for this case since there might be missing metadata.

I actually managed to mount the damn thing after rebooting the server with the second cache drive disconnected, then going

> mount -o degraded,usebackuproot,ro /dev/sdf1 /mnt/disks/2TB/cachefail

 

2TB being an USB3 drive I mounted with the unassigned device plugin (the same command failed when the array is started, so thanks UD plugin!)

 

a little LS showed me the oh so much so anticipated folders:

Yes, my cache pool was the one holding:

-appdata

-system

-a network share with YEARS of benchmark results and homemade bash-scripts to fix stuff / try stuff

-DomainsC being the share holding >THE BOOT DRIVES< of 3 VMs!

 

I dared to move all that to cache when (I thought) I made it a raid1 pool. This bug is BS.

 

Imma gonna >cp it all in an other folder of that usb drive and recreate my cache-pool from scratch.

 

 

 

Worse part being that imo: 

Jan 17 13:14:45 Procyon kernel: BTRFS warning (device sdf1): devid 2 uuid 0cc9242b-012c-47ba-8fb5-5c189ca86901 is missing

It KNOWS somehow which is devid 2, and devid 2 is now connected, but it doesn't hecking pick it up!!

Edited January 17, 20206 yr by Keexrean

Tried if the data was clean by just making an other copy of the recovered shares to the array and trying to run docker, vms and so on from the array. Worked perfectly.

 

Then secure erased both SSDs, cleanly added them back as cache drives, checked the parity status, then now am using the mover to push shares back to the cache with the "Prefer" caching profile, before putting them back to "Cache Only".

 

 

imho devs should push a patch/update that would prompt the user into running >btrfs balance start -mconvert=raid1 /mnt/cache  , because I'mp pretty convince a lot of people out there might have the issue under their radar, ready for a miserable loose cable or failing drive to just do them in the back IO.

Edited January 17, 20206 yr by Keexrean