foreseeable-concertina5279

I think its an issue with JMB585 and WD drives. Noticing the same thing.

I went the nuclear route :). Switched to truenas scale, no issues now.

Having a similar issue to: When there is high IO Wait on Unraid, for some reason I start to see tons of accesses on /boot/bzfirmware. My flash USB is constantly reaching reads of 10MB/s and I'm unsure why. Doing an FATrace doesn't tell me much, here is some example output: ``` emhttpd(6734): RO /boot/config/shares/zfs_backup.cfg emhttpd(6734): C /boot/config/shares/zfs_backup.cfg kworker/u24:4+loop1(3905389): R /boot/bzfirmware kworker/u24:4+loop1(3905389): R /boot/bzfirmware kworker/u24:4+loop1(3905389): R /boot/bzfirmware kworker/u24:4+loop1(3905389): R /boot/bzfirmware kworker/u24:4-loop1(3905389): R /boot/bzfirmware parity_list(3752825): RO /boot/config/plugins/dynamix/dynamix.cfg parity_list(3752825): C /boot/config/plugins/dynamix/dynamix.cfg emhttpd(6734): O /boot/config emhttpd(6734): R /boot/config emhttpd(6734): RCO /boot/config/Trial.key emhttpd(6734): RO /boot/config/Basic.key emhttpd(6734): C /boot/config/Basic.key emhttpd(6734): RCO /boot/config/Plus.key ``` I'm at a bit of a loss here, I'm not sure why these kworker accesses on /boot/bzfirmware startwhen I startdocker containers with high IO (in this example Storj). Any ideas on how to debug or what I can do to solve this? Almost ready to give up on unraid at this point since its causing a ton of system instability (the whole docker daemon slows down, causing the dashboard and the docker page to take forever to load). I think the main dashboard triggers a `docker info` which takes ages when this happens.

I was able to restore the partition table and the data was still there, but the resilver had already started/ZFS didn't reonline the disk (I think it needs a fill import/export). It makes the resilver a bit more risky as it can't use the old disk to verify checksums. I think this caused a few errors to pop up for me (I ended with 1-5 read/checksum errors after the resilver, not sure if thats normal).

I'm on Unraid 6.12.10, every time I do a replace following the guide via the GUI, it seems like it totally brings the old disk offline. For example looks like: ``` NAME STATE READ WRITE CKSUM primary DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 sdc1 ONLINE 0 0 0 sdg1 ONLINE 0 0 0 sdj1 ONLINE 0 0 0 replacing-3 DEGRADED 0 0 0 1123165010249792881 UNAVAIL 0 0 0 was /dev/sdi1 sdd1 ONLINE 0 0 0 ``` Is there any way to adjust it so that the replace doesn't UNAVAIL the previous disk, and can use it for the reslivering process? It seems like the partition that was on /dev/sdi is just gone now that its removed from the pool. # fdisk -l /dev/sdi Disk /dev/sdi: 16.37 TiB, 18000207937536 bytes, 35156656128 sectors Disk model: WDC WD180EDGZ-11 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Wondering if there is any way to fix this.

@JorgeB I'm on Unraid 6.12.10, every time I do a replace following the guide via the GUI, it seems like it totally brings the old disk offline. For example looks like: ``` NAME STATE READ WRITE CKSUM primary DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 sdc1 ONLINE 0 0 0 sdg1 ONLINE 0 0 0 sdj1 ONLINE 0 0 0 replacing-3 DEGRADED 0 0 0 1123165010249792881 UNAVAIL 0 0 0 was /dev/sdi1 sdd1 ONLINE 0 0 0 ``` Is there any way to adjust it so that the replace doesn't UNAVAIL the previous disk, and can use it for the reslivering process? It seems like the partition that was on /dev/sdi is just gone now that its removed from the pool. # fdisk -l /dev/sdi Disk /dev/sdi: 16.37 TiB, 18000207937536 bytes, 35156656128 sectors Disk model: WDC WD180EDGZ-11 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Fair enough, using the docker now! Honestly probably a better solution anyways, thanks for the suggestion. Didn't realize they ran the same script.

Haha I wish lol. Have had one going since I initially posted, its running the final cycle now. Its a USB 3.1 enclosure and they're HDDs, so USB shouldn't be a bottleneck. ~600 MBps is 4.8 Gbps

Don't mean to be a bother, but any update here? They're 10TB disks so would like to do in parallel to save time. Otherwise I'm looking at a few days per disk. Could I just start a bunch of tmux sessions and trigger the commands manually using the disk path?

Thanks for taking a look! DM'd it to you.

I attached an image, but have 3 disks connected via an external JBOD enclosure, and they all seem to have the same identification number, serial for all is (20170331000C3). This means I cannot start multiple concurrent preclears, as it seems to think all are active when I start on a single disk. Any ideas on ways to get around this?