1 minute ago, trurl said:

Rebuild will affect transfer performance, and transfer will affect rebuild performance. I usually don't use the array much during rebuild or parity checks. Maybe just a small file occasionally. Anything going on in the pools will be fine, such as cached user share writes, dockers that aren't writing much to the array, etc. Most of my downloading goes to pools, for example, before it winds up on the array for long term.

Yep that was my thought, i shall wait. I do move/download to the cache pool first, but its only 2tb and in this case if I move its going to be around 10tb so certainly just wait.

Thanks for the diagnostic info, Ive basically just been looking at syslog so good to know. Checking out the rest now, gives me stuff to research i understand 60% of this. Let me know if you found any other no nos while sorting through my junk haha. I really sad thing is I was ready to move to a new case for better cooling this weekend, but that will wait for a bit now. May I ask why you don't use hot swap cases / racks on either of your servers? I tried one years and years ago first doing large data stuff and never looked back

My main server has a backplane for 5 disks, so I could "hotswap". But not much point in really doing things "hot". Unraid won't do anything with a new disk until you assign it, and you can't assign a disk without stopping the array.

You might set your mover schedule so it doesn't run until after the rebuild.

Speaking of that shareDisks.txt, here is yours:

a----------------2                shareUseCache="no"      # Share does not exist
a----------------1                shareUseCache="no"      # Share does not exist
a----------------1 (1)            shareUseCache="no"      # Share does not exist
appdata                           shareUseCache="only"    # Share exists on cache
d--a                              shareUseCache="yes"     # Share exists on cache, disk2, disk4, disk5
domains                           shareUseCache="no"      # Share exists on cache
D-------s                         shareUseCache="no"      # Share does not exist
e-------n                         shareUseCache="no"      # Share exists on disk3, disk4, disk5, cache
isos                              shareUseCache="no"      # Share does not exist
system                            shareUseCache="prefer"  # Share exists on cache

All of those "not exist" are .cfg files for shares that no longer exist for some reason. You can clean that up with the CLEAN UP button on the User Shares page.

You can see one share configured to be moved from cache to the array, and it has some files on cache.

You can also see a share starting with 'e' which is not configured to use cache, but it has files on cache. Telling a share to not use cache won't move anything already on cache.

You might as well set system to only use cache, since its files are already allocated there and don't need to be moved, and won't overflow.

11 minutes ago, trurl said:

My main server has a backplane for 5 disks, so I could "hotswap". But not much point in really doing things "hot". Unraid won't do anything with a new disk until you assign it, and you can't assign a disk without stopping the array.

You might set your mover schedule so it doesn't run until after the rebuild.

Speaking of that shareDisks.txt, here is yours:

a----------------2                shareUseCache="no"      # Share does not exist
a----------------1                shareUseCache="no"      # Share does not exist
a----------------1 (1)            shareUseCache="no"      # Share does not exist
appdata                           shareUseCache="only"    # Share exists on cache
d--a                              shareUseCache="yes"     # Share exists on cache, disk2, disk4, disk5
domains                           shareUseCache="no"      # Share exists on cache
D-------s                         shareUseCache="no"      # Share does not exist
e-------n                         shareUseCache="no"      # Share exists on disk3, disk4, disk5, cache
isos                              shareUseCache="no"      # Share does not exist
system                            shareUseCache="prefer"  # Share exists on cache

All of those "not exist" are .cfg files for shares that no longer exist for some reason. You can clean that up with the CLEAN UP button on the User Shares page.

You can see one share configure to be moved from cache to the array, and it has some files on cache.

You can also see a share starting with 'e' which is not configured to use cache, but it has files on cache. Telling a share to not use cache won't move anything already on cache.

You might as well set system to only use cache, since its files are already allocated there and don't need to be moved, and won't overflow.

i feel like youve looked into my soul sir

so all the a........ not existing are failed appdata backups? it created them at first somehow, not it works correctly, but I never knew how or if i could safely delete them.

the e..... not using cache is long term backup disk3 is part of, rarely does anything once I filled it, I probaly just never set it to use cache, but I should.

How does one set cache for the whole system? i only know how to set it by share. Also if it did hit the overflow point, does it pause until enough room, or just skip the cache and move straight in that instance?

1 hour ago, DiscoStu said:

all the a........ not existing are failed appdata backups? it created them at first somehow, not it works correctly, but I never knew how or if i could safely delete them.

You must have deleted the folders or they would still be user shares.

User Shares are simply the combined top level folders on array and pools.

If you create a user share in the webUI, Unraid creates top level folder(s) named for the share as needed in conformance with the settings for that share.

Conversely, any top level folder on array or pools is automatically a user share named for the folder. If you don't make settings for a share it has default settings.

You probably had appdata backup or something create folders at the top level so they became user shares. The folders are gone now but the .cfg for the shares are still on the flash drive.

2 hours ago, trurl said:

You can clean that up with the CLEAN UP button on the User Shares page.

1 hour ago, DiscoStu said:

the e..... not using cache is long term backup disk3 is part of, rarely does anything once I filled it, I probaly just never set it to use cache, but I should.

Whether or not you set it to use cache, it already has files on cache and they will stay there until you move them manually, or until you configure the share so mover will move them to the array.

1 hour ago, DiscoStu said:

How does one set cache for the whole system? i only know how to set it by share.

Whether and how a user share uses cache is in the settings for the share. The only setting that applies to cache (or other pool) for the whole system is Minimum Free. Each pool has a Minimum Free Setting.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/cache-pools/#minimum-free-space-for-a-cache-pool

Each User Share also has a Minimum Free setting, as well as other settings that control how it stores data on the array and pools.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/shares/#user-shares

2 hours ago, DiscoStu said:

Also if it did hit the overflow point, does it pause until enough room, or just skip the cache and move straight in that instance?

Unraid never "pauses" even when a disk fails. If a disk fails and you still have redundancy from parity, it will just continue to write parity so the write can be recovered by rebuilding.

If for some reason a write can't be completed, such as when you don't have redundancy, or you don't have enough space based on how you have a share configured, it won't wait, it will just fail to write.

It can't wait for something to change that will make the write work since it has no reason to expect that to happen.

A user share will overflow to its Secondary when it needs to write a file and Primary is below Minimum Free.

When it needs to write a file to the array, either because the share is configured to write to the array, or because it has overflowed to the array, if an array disk has less than Minimum Free for the share, it will choose another array disk.

Note that Minimum Free doesn't say how much space to keep free on pool or array disk. It just says how much must still be available for the pool or array disk to be chosen for writing.

In the general case, Unraid has no way to know how large a file will become when it chooses a destination for the file. If the destination has more than Minimum, it can be chosen, and if the file won't fit the remaining free space, the write will fail when it runs out of space. It won't stop and try to move it somewhere else instead.

Thanks again for your help and the info dump. I have a lot to do when I'm back stable.

Update, I now have disk1 back to stable, mounted the old disk1 and files are copying now. I tested move vs copy and doesn't seem to have any speed difference, so stuck with copy just in case something goes wrong.

I've never done transfers from a mounted disc outside of the array like this, is it supposed to be quite slow? seems pretty consistent around 25-35 MB/s.(update: found out about turbo/reconstruct write and now its closer to 100-125MB/s so not terrible)

Also I do feel like I should have some sort of conclusion to this thread for people looking in the future... I suppose we are blaming the usb error, or I somehow messed up the filesystem check then fix? I'm unclear how I would even recreate what happened the first time (erasing just disc1s info)

Edited February 1Feb 1 by DiscoStu

13 minutes ago, DiscoStu said:

I tested move vs copy and doesn't seem to have any speed difference, so stuck with copy just in case something goes wrong.

Copy is safer and faster. It would be noticeably faster if both disks were in the array. Move is Copy from source to destination, the delete from source. Both the copy and the delete are write operations that would update parity.

17 minutes ago, DiscoStu said:

I've never done transfers from a mounted disc outside of the array like this, is it supposed to be quite slow? seems pretty consistent around 25-35 MB/s.

You must not have paid attention, until now, how slow writes to the parity array are. Reading the Unassigned disk is definitely not the bottleneck. Those speeds are typical for writes to the parity array.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/overview/#array-write-modes

22 minutes ago, DiscoStu said:

some sort of conclusion to this thread for people looking in the future

On 1/29/2026 at 9:03 PM, trurl said:

No way to know at this point what happened before you started this thread

I guess we will know how it ended, but not how it started.

Just now, trurl said:

I guess we will know how it ended, but not how it started.

haha bummer, just feel bad for future guy in the same boat.

I've just learned about turbo or reconstruct write, and now its around 100MB. Is this safe to use during this move, and keep on after as well?

Edited February 1Feb 1 by DiscoStu

3 minutes ago, DiscoStu said:

haha bummer, just feel bad for future guy in the same boat.

I've just learned about turbo or reconstruct write, and now its around 100MB. Is this safe to use during this move, and keep on after as well?

This is a good use case for it. I don't use it regularly since it keeps all disks spunup. I cache user share writes instead, which is SSD so even faster than turbo, then they get moved to the array in the middle of the night.

But mover is intended for idle time, so anytime you need to write more than cache can hold, don't cache, use turbo instead.

33 minutes ago, trurl said:

Reading the Unassigned disk is definitely not the bottleneck

Could be if it were connected USB2.

On 2/1/2026 at 6:09 PM, trurl said:

This is a good use case for it. I don't use it regularly since it keeps all disks spunup. I cache user share writes instead, which is SSD so even faster than turbo, then they get moved to the array in the middle of the night.

But mover is intended for idle time, so anytime you need to write more than cache can hold, don't cache, use turbo instead.

Thanks as always, I figure I will leave it on while doing these big moves, then put it back to auto or normal. Quick question, I am allllmost done with all the moves and organization, and suddenly speeds have again dropped off a ton. I noticed 2 things likely related...

Disk4 is either not reading at all, or reading at kb/s speeds. While im on turbo this seems strange, but all smart tests say 4 is just fine. This is also my oldest drive and wouldn't be surprised if it is dying from all these transfers.

Also noticed that even when I paused/finished all the transfers that I was running (and neither mover/parity check running at the time) that my disks were all still reading or writing at decent speeds. Couldn't find what they were doing, even had all my dockers closed at the time.

discoraid-diagnostics-20260202-2318.zip

1 hour ago, DiscoStu said:

my disks were all still reading or writing at decent speeds. Couldn't find what they were doing,

Turbo (reconstruct write) reads all drives in parallel so parity can be calculated and written at the same time the data disk is written.

1 hour ago, DiscoStu said:

Disk4 is either not reading at all, or reading at kb/s speeds.

Disk4 is your smallest disk so it will typically be the slowest.

All disks are faster on the longer outer tracks than on the shorter inner tracks because the longer tracks have more data than the shorter tracks, but the RPM is constant.

Since disk4 is smaller, sometimes it isn't involved because it doesn't have any data to contribute when writing to the "extra" space on the larger disks.

Disk Speed docker will let you benchmark each of your disks and give graphs comparing speed at different parts of each disk, and comparing disks to each other.

8 hours ago, trurl said:

Turbo (reconstruct write) reads all drives in parallel so parity can be calculated and written at the same time the data disk is written.

Disk4 is your smallest disk so it will typically be the slowest.

Sorry I probably wasn't super clear, 2 separate confusions....I do understand all discs read on turbo mode, I was just trying to figure out what they were reading, as I wasn't transferring, no dockers running, etc etc. It did eventually relax and spin down, so no worries.

As for disk4 I didn't consider the physical platter sizes, so certainly part of it. I was watching it closely later and did notice times where it was at 70% or so of the other discs which made sense. But some of the time it was at like 0.5% of the other drives speeds so I do think that drive might be hurting.

Thanks again for talking me through. Plan to do parity check, backup to the offline drives again this week, and if everything is stable move to the new case this weekend.

51 minutes ago, DiscoStu said:

the physical platter sizes

The size is the same but the density has increased as newer drives have gotten more capacity.