Wrecked my array (Cache pool unmountable)

[Matthews]

I had a problem with an unmountable cache drive that did not want to mount. I tried saving the backup data (wasnt that important, just metadata I belive).

 

I found this topic and followed the instructions 

 

Now I believe I have just destroyed my array with the command below and lost it all:
 

For a cache device (or pool) stop the array and use sdX:

btrfs check --repair /dev/sdX1

Replace X with actual device (use cache1 for a pool), don't forget the 1 in the end, e.g., /dev/sdf1

 

 

I cant get any diagnostics, nothing worked. I tried restarting the server to see if the issue would at least let me to get back to the array (worked when I did the mount function).

Any help appreciated, I am lost with btrfs! 

[Matthews]

Somehow im still logged in my browser so I can access the terminal window. I dont know if this helps..

[Matthews]

I decided that if all else has failed that the problem might be the USB stick. 

Took it out and ran chkdsk and it came back okay. I decided i would try a fresh instal of unraid and voila it worked! 

I re-added every disk in the right slot and it seems all the data is intact, except dockers and settings need to be reconfigured but im looking it as a plus, it might be more stable this way and I get to maybe optimize certain settings all over again! I am really happy, I basically gave up when i got that message and was sure all was lost!


I did notice i have a cache drive in btrfs and the array in xfs, which is strange. Should I reformat the cache drive to xfs? (I read that it is not the best to have the cache in btrfs formating as problems are more common. I am looking for stability)

[trurl]

btrfs is default for cache and other pools since it lets you have multidisk pools. If you don't intend to you can change it to XFS.

[trurl]

26 minutes ago, Matthews said:

the problem might be the USB stick

Your symptoms seem more like you had filled rootfs. That is where the OS keeps its files and if you fill it up all sorts of things can go wrong since the OS has no space to work in.

 

The usual cause of filling rootfs is something writing to a path that isn't actual storage, such as an incorrect host path in a docker.

 

Probably your fix was overly drastic and not really the fix, but since you will be setting things up again maybe you can fix them.