I've been dealing with getting a bad drive out of the system (I think it's a bad cable, actually) until I can figure out how to resolve it.

I unmounted the drive and did a "new config" to get the rest of the drives working on the array

 

however, my cache drive has been filling up and the mover doesn't seem to be moving anything. I moved some things manually (to the mounted disk themselves) to work around it overnight, but today it's still happening

 

I noticed some files weren't being picked up so I tried to move them manually again today (this time to just a basic user share) and windows says it can't do that. something about an i/o error.

 

I'm wondering if that's why the mover is failing and stopping the process without actually moving anything.

 

here's my diagnostic file. is there anything that stands out?

tower-diagnostics-20201128-0852.zip

Probably best to run the File system check against disk 17 after reseating the cable to it

23 minutes ago, Squid said:

Probably best to run the File system check against disk 17 after reseating the cable to it

disk 17 being "sdv"? I think the bad disk I mentioned was in that disk 17 slot before (is disk sds). but it's currently sitting unmounted in the case

I will recheck that cable, but I'm not sure if I've had any errors reported on disk sdv yet (yet is likely the key word here)

 

thanks for  the heads up. will look into that file system check today

10 minutes ago, Endda said:

disk 17 being "sdv"

If you fix filesystem on an sd device in the array you will invalidate parity. You must use the md device

 

So disk17 is md17 unless you use encryption.

 

Best if you just go through the webUI to check filesystem then it will use the correct device:

 

https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

Your syslog is showing corruption on disk17 is the reason for the suggestion.

 

Also, why do you have 50G allocated to docker.img? 20G is usually much more than enough. Have you had problems filling docker.img?

 

And, your appdata has files on the array. You will have to set it to cache prefer so mover can move those to cache.

 

Note that mover can't move open files, so you will have to disable Docker in Settings before running mover.

1 hour ago, trurl said:

And, your appdata has files on the array. You will have to set it to cache prefer so mover can move those to cache.

the appdata share is set to cache only. there's no need to move any appdata information to the array

2 minutes ago, Endda said:

the appdata share is set to cache only. there's no need to move any appdata information to the array

With appdata set to Use cache=only any files belonging to appdata that are on the array will be left there as mover ignore any shares where Use Cache is set to ‘only’ or ‘no’.

2 hours ago, Endda said:

the appdata share is set to cache only. there's no need to move any appdata information to the array

I could see appdata has files on the array from your Diagnostics and I could also see that appdata is set cache only. 

 

4 hours ago, trurl said:

You will have to set it to cache prefer so mover can move those to cache.

 

Note that mover can't move open files, so you will have to disable Docker in Settings before running mover.

 

3 hours ago, Endda said:

the appdata share is set to cache only. there's no need to move any appdata information to the array

You can see how much of each disk is used by each user share by clicking on Compute... on the User Shares page.

39 minutes ago, trurl said:

You can see how much of each disk is used by each user share by clicking on Compute... on the User Shares page.

thanks. seems those were just old instances of misconfigured docker images. one hadn't even been modified since 2015.

I deleted the folder to remove the old data