Endda Posted November 28, 2020 Share Posted November 28, 2020 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 Quote Link to comment
Squid Posted November 28, 2020 Share Posted November 28, 2020 Probably best to run the File system check against disk 17 after reseating the cable to it 1 Quote Link to comment
Endda Posted November 28, 2020 Author Share Posted November 28, 2020 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 Quote Link to comment
trurl Posted November 28, 2020 Share Posted November 28, 2020 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 1 Quote Link to comment
trurl Posted November 28, 2020 Share Posted November 28, 2020 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. Quote Link to comment
Endda Posted November 28, 2020 Author Share Posted November 28, 2020 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 Quote Link to comment
itimpi Posted November 28, 2020 Share Posted November 28, 2020 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’. Quote Link to comment
trurl Posted November 28, 2020 Share Posted November 28, 2020 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. Quote Link to comment
trurl Posted November 28, 2020 Share Posted November 28, 2020 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. Quote Link to comment
Endda Posted November 28, 2020 Author Share Posted November 28, 2020 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.