Tomr
-
Posts
23 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by Tomr
-
-
8 minutes ago, JorgeB said:
The please post new diags and the output of:
btrfs fi usage -T /mnt/disk1
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.
Quote
root@Tower:~# btrfs fi usage -T /mnt/disk1
Overall:
Device size: 10.91TiB
Device allocated: 8.41TiB
Device unallocated: 2.50TiB
Device missing: 0.00B
Used: 8.07TiB
Free (estimated): 2.83TiB (min: 1.58TiB)
Free (statfs, df): 2.83TiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: noData Metadata System
Id Path single DUP DUP Unallocated
-- -------- ------- -------- -------- -----------
1 /dev/md1 8.38TiB 32.00GiB 16.00MiB 2.50TiB
-- -------- ------- -------- -------- -----------
Total 8.38TiB 16.00GiB 8.00MiB 2.50TiB
Used 8.05TiB 9.36GiB 1.25MiB -
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.
-
-
6 minutes ago, dlandon said:
Remove the UD plugin and see if the reads and writes continue to increment on the stock UD page.
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.
-
They don't state that the files will be orphaned if the setting are changed, or the whole things with hardlinks. And I was assured that would work as I expected because of this:
-
I understand that it might be designed that way, but that doesn't mean it's correct. I only discovered that because I tried to write my custom mover scheduler, otherwise I would found out it the hard way with no space left in pools.
At the very least this should be explained better in tooltips.
[6.10.0-RC1] Parity rebuild uses unassigned device(?)
-
-
-
-
-
in Prereleases
Posted
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