Gico

I cancelled, but why unraid won't stop the parity sync if it's unreliable? Similarly when at first I added the 2nd parity drive, and one disk was disabled, parity sync continued without writing further to the new parity disk, so again..imo unraid should have stopped the parity-sync. Will update when I'll get home. Edit: How do the smart reports of disk5 and disk 11 look like? Are they ok apart from the read issues which might be caused by cables?

But if the disk still has a green dot, doesn't it mean that the fs overcame this issue and the data was read successfully?

Attached. juno-diagnostics-20230627-1201.zip

Parity-Sync is going quite slowly at about 55MB/sec, sometimes even slower. disk 5 got again some read errors. still has a green dot, but it's read speed is about twice the speed of other disks so I guess it has issues and it delays the Parity-Sync. Occasionally disk 11 speeds also has faster read speed than the rest of the disks. Both disks are of the same model (Seagate 16TB HDD Exos X16) and bought together on Amazon. They are probably out of warranty. My questions: - Can I pause the Parity-Sync, shut down the server to check/replace cables and continue the Parity-Sync after boot? - Can I somehow check the disks before starting back the array? maybe mount in read-only and do data-read-test somehow? Attached smart from both disks juno-smart-20230627-1006.zip juno-smart-20230627-0927.zip

Yes I'm sure 🙂 Anyway this saga ended for now: Stopped the array, changed the fs type to xfs and started in maintenance mode. xfs_repair -n still seemed ok. xfs_repair generated this error: ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. So I stopped the array and tried again (Unsuccessfully) to mount. Next was maintenance mode again and xfs_repair -L which WAS SUCCSSFULL. All drives are mounted, content of disk5 seems ok, and Parity-Sync is running. Thanks a lot @JorgeB and @itimpi!

I rebooted, started in maintenance mode and executed xfs_repair -n for disks 5 and 11. Logs attached. They seemed ok to me so I did new config, preserved all current assignments and started the array. Disk 11 is mounted, Disk 5 is not (syslog following), so now I think only option is maintenance mode and xfs_repair with correction, right? The disk fs type is set to "auto" so I can't execute the command from the gui. Any ideas / What is the command I need to run? Jun 25 13:59:01 Juno emhttpd: mounting /mnt/disk5 Jun 25 13:59:01 Juno emhttpd: shcmd (279): mkdir -p /mnt/disk5 Jun 25 13:59:01 Juno emhttpd: shcmd (280): mount -t xfs -o noatime,nouuid /dev/md5p1 /mnt/disk5 Jun 25 13:59:01 Juno kernel: XFS (md5p1): Mounting V5 Filesystem Jun 25 13:59:02 Juno kernel: XFS (md5p1): Corruption warning: Metadata has LSN (4:1317887) ahead of current LSN (4:1316525). Please unmount and run xfs_repair (>= v4.3) to resolve. Jun 25 13:59:02 Juno kernel: XFS (md5p1): log mount/recovery failed: error -22 Jun 25 13:59:02 Juno kernel: XFS (md5p1): log mount failed Jun 25 13:59:02 Juno root: mount: /mnt/disk5: wrong fs type, bad option, bad superblock on /dev/md5p1, missing codepage or helper program, or other error. Jun 25 13:59:02 Juno root: dmesg(1) may have more information after failed mount system call. Jun 25 13:59:02 Juno emhttpd: shcmd (280): exit status: 32 Jun 25 13:59:02 Juno emhttpd: /mnt/disk5: no btrfs or device /dev/md5p1 is not single Jun 25 13:59:02 Juno emhttpd: /usr/sbin/zpool import -d /dev/md5p1 2>&1 Jun 25 13:59:02 Juno emhttpd: no pools available to import Jun 25 13:59:02 Juno emhttpd: disk5: no uuid Jun 25 13:59:02 Juno emhttpd: shcmd (281): mount -t reiserfs -o noatime,user_xattr,acl /dev/md5p1 /mnt/disk5 Jun 25 13:59:02 Juno kernel: REISERFS warning (device md5p1): sh-2021 reiserfs_fill_super: can not find reiserfs on md5p1 Jun 25 13:59:02 Juno root: mount: /mnt/disk5: wrong fs type, bad option, bad superblock on /dev/md5p1, missing codepage or helper program, or other error. Jun 25 13:59:02 Juno root: dmesg(1) may have more information after failed mount system call. Jun 25 13:59:02 Juno emhttpd: shcmd (281): exit status: 32 Jun 25 13:59:02 Juno emhttpd: /mnt/disk5 mount error: Unsupported or no file system Jun 25 13:59:02 Juno emhttpd: shcmd (282): rmdir /mnt/disk5 xfs_repair.Disk11.txt xfs_repair.Disk5.txt

Sequence of events: 1. I had a working array with one parity drive and a spare disk already in the server. 2. Stopped the array, assigned the spare disk to 2nd parity and started the array. 3. disk 5 turned invalid (Red X) immediately. 4. I stopped the array, unassigned disk 5, started the array, stopped it, reassigned disk 5 and started it again, so 2nd parity and disk 5 being rebuilt. 5. Overnight disk 11 got read errors, but still in the array (no red-X). Parity built seems to continues, but in main I can see no writes to parity 2 and to disk 5 and also no reads from disk 11. I can access these 2 disks fs, but the files data is corrupted. I had issues with Red-Xs in multiple disks in the past that were caused by insufficient cooling to the server, and in particular to the on board HBA. I'm guessing that the data on these disks is ok, but this needed to be checked when they are unassigned. Ideas how to continue now, please. Update: - disk 11 actually dropped from the array because it appears in the Unassigned Devices list. - I can't stop the Parity operation through the web interface: It just continued when I try. How can I stop it through CLI? juno-diagnostics-20230625-0704.zip

Thanks Djoss. Yes, I have to enter password every time. My user name already exists in the web-ui.

Occasionally (like half the times I try) I can't login the web-ui saying Crashplan is "upgrading to a new version". Looking at the history log I see these messages beginning on March 10th: 06/20/23 04:55 PM CrashPlan started, version 11.0.1, GUID 632038001948010500 06/20/23 04:56 PM Downloading a new version of CrashPlan. 06/20/23 04:57 PM Download of upgrade failed - version 15252000061111, connection lost. 06/20/23 04:57 PM Unable to apply upgrade(s), retrying in one hour Docker image version is 23.06.1 which is the latest. Should the image updated to get rid of this issue? Thanks.

Hi. I scheduled parity check for the first time, with "Use increments for scheduled Parity Check" enabled, and "Write corrections to parity disks" set to to "Yes". This morning I got a notification that "[Juno} paused Scheduled Non-Correcting Parity Check (3.2% completed)". Why does this notification says "Non-Correcting"?

Thanks. How does "Use increments for Parity-Sync/Data Rebuild operations" option should be used? Can/Could it be set to Parity-sync with increments, so that after every increment reached I can/could manually set it to start the next increment, so I would risk only losing progress from the last increment?

Thanks. I'll investigate/prepare this option if this would be the last resort.

I replaced both parity disks and began parity built. It should take more than 3 days. What happens if a power outage happens during the parity built? Does it have to be started from beginning or it continues from where it reached before the outage? I have a UPS that lasts for few minutes, but I moved to a new flat in which power supply is occasionally fails to supply my home's power consumption.

So after 3 years tolerating this issue and restarting the Docker service like every 3 days for a while in order to delete the log file, I found the issue: /boot/config/docker.cfg had that line: DOCKER_OPTS="-D --storage-driver=btrfs" -D implied debug, so debug messages were written to the log. Removing the -D resolved the issue.

Thanks. I checked that the cables are connected and so, but this is still quite strange. In the past I had several times of multiple disks issues at the same time and even loss of data due to FS issues, until I understood that I need to actively cool the onboard HBA. Since then it was smooth sailing, and now it's the same symptoms, but fan is working, the server is not stressed with activity and it's winter so cooler temps, so that's worrying.

Restarted array in maintenance mode, repaired disk11 with xfs_repair. Disk16 required xfs_repair -L to be repaird. Now I restarted the array and still have redX and content is emulated. Disk16 has lost+found directory (expected). So is it now: stop array unassign both disks start array stop array assign disks start array

Hi. I have an array drive with red X. Background is that cache was out of free space, I stopped the array but it couldn't be stopped ("retrying to unmount"). I rebooted the server, started back the array, and parity check began to run. I didn't notice any issue and began to copy from cache to Disk 16, and several minutes afterwards it got a red X. Diagnostics attached. I'm backing up now this disk content to one of the other disks. This will take a lot of time. I stopped the parity check. Afterwards should I start in maintenance mode and check the file system to check if the emulated FS is ok? Diagnostics attached. Edit: Now another disk got an X. Attached updated diagnostics. juno-diagnostics-20220212-0219.zip

All done, Thanks a lot. 1st disk took about 26 hours, the 2nd one 6 hours.

Metadata profile changed to RAID1. Stopped the balancing because anyway the device delete should balance the data to the new disks. Currently running "btrfs device delete /dev/sdm1 /mnt/cache" but counter my expectations, there are no meaningful writes to the new devices. Is that normal? Running "btrfs device usage" I see the data on the two old disks decreasing 3.18Tib --> 3.17Tib --> 3.11Tib... That's freaking me out a bit, although used space on the cache pool seems to be steady. juno-diagnostics-20211129-1636.zip

Thank you. Ran the replace commands but both have same error because SSDs are somewhat smaller than the current cache disks (all 4 disks are "4TB"): ERROR: target device smaller than source device (required 4000786980352 bytes) Any reasonable option to overcome this issue? btrfs resize maybe? Or alternatively add the 2 SSDs to the pool (through GUI?) to have 4 devices on the cache pool, then do "btrfs device delete" one by one?

Hi, Can anyone help with the procedure to replace the 2 cache pool devices (hard disks) with 2 SSDs (sdab, sdak) using CLI? I prefer using CLI (btrfs replace commands) instead of moving the data to the array and then back because I have Plex data, so it will probably take ages. I understand that using the GUI to do it is broken on v6.9.2. Thanks. juno-diagnostics-20211128-0938.zip

I'm not sure if this is related to the OP issue, but I had an issue with "My Servers" constantly backing up the flash every minute. Flash backup initialization solved that. I kept watching the server, found UNRAID-API taking up CPU resources, and this was in the log. I stop the flash backup and started it again on 14:26 through the GUI, and so far all is OK. Sep 27 11:03:57 Juno flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup.php update Sep 27 11:04:57 Juno flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup.php update Sep 27 11:05:58 Juno flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup.php update Sep 27 11:18:45 Juno dhcpcd[2116]: br0: failed to renew DHCP, rebinding Sep 27 12:51:29 Juno emhttpd: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin update unassigned.devices.plg Sep 27 12:51:29 Juno root: plugin: running: anonymous Sep 27 12:51:29 Juno root: plugin: creating: /boot/config/plugins/unassigned.devices/unassigned.devices-2021.09.26.tgz - downloading from URL https://github.com/dlandon/unassigned.devices/raw/master/unassigned.devices-2021.09.26.tgz Sep 27 12:51:30 Juno root: plugin: checking: /boot/config/plugins/unassigned.devices/unassigned.devices-2021.09.26.tgz - MD5 Sep 27 12:51:30 Juno root: plugin: creating: /tmp/start_unassigned_devices - from INLINE content Sep 27 12:51:30 Juno root: plugin: setting: /tmp/start_unassigned_devices - mode to 0770 Sep 27 12:51:30 Juno root: plugin: skipping: /boot/config/plugins/unassigned.devices/unassigned.devices.cfg already exists Sep 27 12:51:30 Juno root: plugin: skipping: /boot/config/plugins/unassigned.devices/samba_mount.cfg already exists Sep 27 12:51:30 Juno root: plugin: skipping: /boot/config/plugins/unassigned.devices/iso_mount.cfg already exists Sep 27 12:51:30 Juno root: plugin: skipping: /tmp/unassigned.devices/smb-settings.conf already exists Sep 27 12:51:30 Juno root: plugin: skipping: /tmp/unassigned.devices/config/smb-extra.conf already exists Sep 27 12:51:30 Juno root: plugin: skipping: /tmp/unassigned.devices/add-smb-extra already exists Sep 27 12:51:30 Juno root: plugin: setting: /tmp/unassigned.devices/add-smb-extra - mode to 0770 Sep 27 12:51:30 Juno root: plugin: skipping: /tmp/unassigned.devices/remove-smb-extra already exists Sep 27 12:51:30 Juno root: plugin: setting: /tmp/unassigned.devices/remove-smb-extra - mode to 0770 Sep 27 12:51:30 Juno root: plugin: running: anonymous Sep 27 14:22:34 Juno unraid-api[10980]: ⚠️ Caught exception: WebSocket is not open: readyState 0 (CONNECTING) Sep 27 14:22:34 Juno unraid-api[10980]: ⚠️ UNRAID API crashed with exit code 1 Sep 27 14:26:36 Juno flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup.php update

DEPRECATED! Updated yesterday and can't connect today. This is what the log says, and of course you find out about that only when you're away... ****************************************************** ****************************************************** * * * * * This image is deprecated. * * We will not offer support for this image * * and it will not be updated. * * * * * ****************************************************** ****************************************************** We recommend our wireguard image instead for vpn: https://github.com/linuxserver/docker-wireguard ****************************************************** ****************************************************** [cont-init.d] 99-deprecation: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done.

Considering current situation where disk space is much cheaper than a beefy CPU, My strategy is having a 1080p version for every 4K media. Plex handles them well: You have a "Play version" option.