Tomr

Not only a visual one as it prevented spindown's and/or woke up the disk immediately when I tried to spin down it manually. I made a new diag now and a screenshot after clearing the stats and doing a small write to disk1. Nothing is written on that unassigned device. tower-diagnostics-20211018-1941.zip

The disks are not connected, how could they be. That drive drive that has incorrect counters is not being actually used for anything, just the counters are wrong.

They were both in the array (one was disk1, the other one was disk3), I created new config, removed the disk3 from the array and started the array to rebuild the parity. I wanted that disk3 to be unassigned. The thing is it didn't have activity, GUI and other monitoring apps showed it at 0MB/s read & write when the parity was rebuilding, it's just the read and write count in GUI that were inaccurate (and mirroring disk1's count), and because of that it wouldn't spin down. I removed the drive from it's own pool to test your theory about wiping, that those drives were somehow connected (if they were it would be a different Unraid bug) and it's again mirroring reads & writes count from disk1.

They were both in the array, not pool devices. They were btrfs, but they were separate disks, not part of a jbod or raid1.

Parity rebuild is done, it's still mirroring the stats and preventing spindown. I rebooted the machine to see if it fixes it, it didn't. I changed the slot amount from 7 to 5 (to remove the empty ones); nope. It only got "fixed" when I created new pool and assigned this drive to it. But it's not really a fix If I wanted to have an unassigned device.

tower-diagnostics-20211016-1344.zip

I did that, it still does increment. EDIT: I made some tests with writes and it seems that the unassigned device "copies" it's read/write count from disk1.

That didn't help, I've posted a report here

I removed one of the drives from the array, created new config and let it recreate parity. But it seems that it's using unassigned device (the one I removed) for some reason. You can see the reads amount on the screen, it's on par with the array disks and is growing with them. dstat shows 0MB/s read and write on it though, so it might be a visual bug. But on the other hand, it won't let me spin-down this drive, logs will show: I don't know if it's UA's bug or Unraid one and I'm screwing up my parity. I'm on 6.10.0 RC1

Could you update jdupes to newer version? Current version is bugged, see: https://github.com/jbruchon/jdupes/releases for 1.15 release. I personally would like/need at least 1.18.1 for the newer/older filter

I wonder why it didn't recognize the correct signature then.

The thing is I didn't tell it to format anything. I just added new slot, started the array and it went up straight to cleaning it. Now that I think about it, it's prob because my array is encrypted.

Everything went fine, I received email saying so, and I also checked the logs. That means preclear doesn't do anything when adding new drive? That's strange. I thought Unraid should pickup that the disk is precleared and go straight to syncing parity. I didn't format the disk as trurl wrote, just preclear.

In 6.9, I did a preclear on disk, using Joe-L, skip pre-read and selected fast post-read. It finished, I got notification on email so I added it to the array (new slot), and unraid clears the disk again ("Clearing in progress"). Is it normal? Or it happened because I didn't click the red "X" button after the preclear? I thought pre-clearing's purpose was to not have to clear it when adding to array.