ffaat

For what it's worth after having multiple database corruptions and having to rebuild twice from scratch (even having set up backups) I gave up and spent $90Cdn to buy an OC200 controller. It's been a much more pleasant experience. Rob A.

Likely too late to help but the same happened to me. Known issue when updating the container: https://github.com/mbentley/docker-omada-controller?tab=readme-ov-file#controller-upgrades From that link: I had to completely rebuild my configuration as the database was corrupted after I just clicked the update button in Unraid. -Rob A.

woot! Thanks @JorgeB. I was successfully able to use mover to get everything onto the array, reformat the drives as a ZFS mirror and then restore everything back tot he cache. Any tips on setting up a regular docker.img and appdata backup routine? -Rob A.

Yes I can still access the data after the reboot. Unfortunately I can't scrub as it is mounted read only: root@STORAGE:~# btrfs scrub start -B /mnt/cache/ ERROR: scrubbing /mnt/cache/ failed for device id 1: ret=-1, errno=30 (Read-only file system) ERROR: scrubbing /mnt/cache/ failed for device id 2: ret=-1, errno=30 (Read-only file system) scrub canceled for 769a2235-054f-413d-bb43-68b51c7171de Scrub started: Fri Jul 19 10:02:26 2024 Status: aborted Duration: 0:00:00 Total to scrub: 0.00B Rate: 0.00B/s Error summary: no errors found Any other suggestions? (On a side note - I never had this type of problem in the past.... is btrfs really ready for prime time? or should I rebuild the cache as ext4?)

Rebooted and array started. diags attached... TIA! storage-diagnostics-20240719-0830.zip

I've dug in the forums and found various similar issues identified, but figured as I'm only moderately experienced with linux I should post here before taking the nuclear option. Last night we had a power outage in my building and today I see my dockers are "running" but not working. I had appdata on my mirrored cache drives, and it looks like I have the dreaded error fillimg my logs: Jul 18 16:50:26 STORAGE kernel: BTRFS error (device sdf1: state EA): bad tree block start, mirror 2 want 271073280 have 0 sdf is one of my cache pool SSDs, and sdg is the other. So before I completely blow away my cache dives and rebuild all my dockers, hoping there my be something else I can do to make this easier. (though when I look into the cache drive, many of the appdata\dockername\ folders are empty... possibly to more than one restart as the power did cycle several times over an hour. (Yes, I know I should get a UPS.... lesson learned....) Diagnostics attached, Thanks in advance. storage-diagnostics-20240718-1755.zip

Alas - I did, but hadn't noted them down... WIll I have to try and reconstruct from memory or can I find artifacts within the contrainers or old configuration to indicate what they were? TIA-

I did that, and now have no dockers... Can I restore them from the backed up folders some how?

fdisk -l /dev/sdf returns: Disk /dev/sdf: 476.94 GiB, 512110190592 bytes, 1000215216 sectors Disk model: SanDisk SDSSDH3 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdf1 2048 1000215215 1000213168 476.9G 83 Linux and btrfs rescue zero-log /dev/sdf1 returns: Clearing log on /dev/sdf1, previous log_root 2131132416, level 0 Diags atached. Cache array is up but my dockers seem all borked: Any suggestions on next steps? storage-diagnostics-20240313-2103.zip

I was out of town for the weekend and we had a sustained poweroutage. When I came back home I discovered the same issue as : https://forums.unraid.net/topic/157633-cache-drive-pool-unmountable-after-restart/ where my cache drives are not recognized which I discovered when none of my dockers existed....: results of btrfs fi show: root@STORAGE:~# btrfs fi show Label: none uuid: 0df9477a-fee8-4858-80b3-1047512917af Total devices 1 FS bytes used 392.00KiB devid 1 size 20.00GiB used 536.00MiB path /dev/loop2 Label: none uuid: f9c6b189-82c9-4a45-b942-064f08446bdf Total devices 2 FS bytes used 8.67GiB devid 1 size 476.94GiB used 45.03GiB path /dev/sdf1 devid 2 size 476.94GiB used 45.03GiB path /dev/sdg1 And both results of fdisk -i: root@STORAGE:~# fdisk -l /dev/sdf1 Disk /dev/sdf1: 476.94 GiB, 512109142016 bytes, 1000213168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes root@STORAGE:~# fdisk -l /dev/sdg1 Disk /dev/sdg1: 476.94 GiB, 512109142016 bytes, 1000213168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes At the sfdisk command I get a different expeience, so posting here... Any suggestion on the next step? Thanks in Advance... storage-diagnostics-20240312-2110.zip

Thanks - it does appear to track. Just looks like the Unraid values lag the ones displayed in Scrutiny by a few minutes. When I saw the 15 deg delta drives had just spun down, and eventually Unraid screen caught up. -Rob A.

Hi- I just noticed that the reported temperatures in the UNRAID main screen (and Dashboard) show values that are about 15deg higher than what is being reported in Scrutiny. Any suggestions on how to troubleshoot this discrepancy? Because Scrutiny provides a (consistent) trend, I'm more inclined to believe those numbers..... Thanks, -RobA>