Hi All,

I've been using Unraid for a few years now and love it. Fairly familiar with all of its features, so this issue is a major headscratcher.

First, I'll say I have two unraid servers, both running 6.12.6.

Primary server does NOT have this issue, secondary does and I can't figure out why...

 

On the "Main" tab, if I am in the "Reads/Writes (IO/s)" mode for the disk counters, they increment as expected while any disk operations are ongoing. 

When I click to change to "bytes" mode, all disks remain at 0 Bytes/sec, forever, while the same operations are running.

I can switch back and forth, in real time white xfers are running, one mode works and one shows constant zero.

 

I can't think of a reason for this behavior, nor can I find a setting that affects the counters and I've been trying for a while.

- I've stopped/started the array, rebooted, etc. No change.

- The array is started and has no errors, parity is valid (one disk)

- Docker running or not (no difference)

- If I log into the server via SSH or the terminal through the WebUI and run "iostak -k 1", I see the disk reads/writes in bytes per second, just as I would expect, so the data is clearly accessible, it is just not making it to the WebUI for some reason.

 

Has anyone else seen this? I'm hoping it's something simple I am overlooking, but I can't imagine what it could be at this point.

Any assistance would be greatly appreciated.

 

Thanks!

 

 

AFAIK the counters are read/write commands, that could lead to negligible actual dat a transfer that's too low to even display.

They are Input/outputs per second (IOPs), and I’m talking like 2k iops per second / 3-400 MB/sec, so not negligible at all.  

Try to clear browser cache/cookies. 

 

 

2 hours ago, infinisean said:

They are Input/outputs per second (IOPs)

 

I was talking of the display in "counter" mode. It's not a "per second", it's a total count.

 

Edited February 3, 20242 yr by Kilrah

I did, and that didn't help... but I did figure out the cause, or at least part of it.

One of my disks filled up at one point, and after that the bytes counters stopped working. Redistributing some data so that disk was no longer full didn't fix the counters, but after the next reboot (once the disk was no longer full), they started working again.

So it seems like it might be some corner-case bug that is only triggered when an individual disk fills up.

 

While that did solve the mystery of the non-functional byte counters, it exposed a different mystery... why that disk filled up to begin with.

I have tried everything I can think of to avoid adding more data to my Disk1 but nothing works.   

 

I tried with it as the lone "exclude" disk, I tried with all disks except 1 as "included", and I tried both together which is redundant and should not be necessary... and every combination of fill-up method, but in every scenario, disk1 still gets all new writes to the point it fills up, even when I have 8 other disks with plenty of space free.

Is there anything I've not covered that would explain why Disk1 keeps getting ALL the damn writes, when it shouldn't?

The other drives work fine..... I can manually copy to them, the "unbalanced" app works fine to redistribute data, etc...  it's just that the "new" data sent to the /mnt/user/data share does not obey the rules I configure to prefer the other disks under any circumstances.

 

Any suggestions would be greatly appreciated.

 

Thanks!

 

1 hour ago, infinisean said:

Any suggestions would be greatly appreciated.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback.  It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

 

The one thing that occurs to me for a potential cause is the Split Level setting on User shares?   This setting takes priority on User shares in case of conflict with other share settings so can force files to a drive because of the path involved.

1 hour ago, infinisean said:

but in every scenario, disk1 still gets all new writes to the point it fills up, even when I have 8 other disks with plenty of space free.

Usually that means you have something that is set up to write directly to /mnt/disk1 instead of /mnt/user, thereby bypassing any automatic redirection.

On 2/4/2024 at 4:01 AM, Kilrah said:

Usually that means you have something that is set up to write directly to /mnt/disk1 instead of /mnt/user, thereby bypassing any automatic redirection.

That would be a reasonable assumption, but it's not the case here. 

I know because I can reproduce the issue easily... i.e. stopping all I/O completely. shutting down docker, and confirming nothing is being written (both on the main tab and using the CLI "iostat -k1")     Zero I/O happening....

 

Then, start a samba file transfer from a another machine on my LAN with 10g of bandwidth available between that host and my unraid server(s) (this happens on more than one now)... and immediately see the drive 1 start showing I/O under these conditions:

 

The array is set to "Most Free" or "High Water"

Split set to "any folder as needed" (originally I had it split on the top 3 dirs due to the way my media is organized, but it behaves the same with both options)

All disks are allowed, none excluded

Disk1 is nearly full

Other disks have much more free space.

 

Under those conditions, I can't understand why it would continue to write to a disk which is nearly full when there are plenty of other available disks.

 

 

Am I missing something obvious, or would I be correct in my assumption that something is not right if the nearly-full disk is being written to (consistently) under the above conditions?

 

 

1 hour ago, infinisean said:

Am I missing something obvious, or would I be correct in my assumption that something is not right if the nearly-full disk is being written to (consistently) under the above conditions?

There's another place to check, in "Global share settings" drives can be included/excluded from being used by any share too.