theruck

i have had high CPU usage too and if i remeber correctly, the mover never moved anything and ended just after i started it. what seemed to resolve the problem was to put the shares into order. as i have played with them in the past i had some leftovers to be synced from cache to disk so make sure that the column STORAGE corresponds to what you see in the SIZE if it says CACHE you shall see the disk usage only on CACHE. if you find discrepancies, move the files through an SSH session from or to the /mnt/user0 for example if you find this it shows that DOWNLOADS share belongs to Array but data on Cache is present so you need to move it manually (or delete from cache) then run the mover to sync things again after that my CPU (and IOWAIT) is back to normal

similar question here. i just heard that my unraid server rebooted and i cannot find a reason while i know it was not me rebooting it or me having any automatic action that would do so server-diagnostics-20231215-1149.zip

there was no way out other than reboot as you can see array is starting but parity check buttons are not there the next teboot the parity check started as you described

after another reboot all is looking ok again and the array starts normally starting a parity check server-diagnostics-20221201-1045.zip server-syslog-20221201-0945.zip

did a clean reboot after changing CPU pinning and getting this after start the array is in starting... state

create a working VM clean then use the imported vmdk file as drive (replace file if possible) to be sure you have a working configuration first

are you copying to a SSD drive on the unraid server?

then you need to try different filesystem or use disk shares instead

try to list the directory with different command if it take so much time too as it might be caused by ls itself. try find or use ls without the sorting - ls -U should be quicker also coloring of files in bash can have an impact on the output it can be also filesystem dependent so you can have different results using XFS

you would know it by the amount of data you need to - copy quickly - have available on the quicker SSD drive due to performance - be proteced thus stored on the HDD with parity as the SSD data is not protected by parity so it really comes up to your use case and type of data and type of storage requirements

your bottleneck is the hard drive speed so you can solve this with a SSD or SSD cache drive only. you would need to size the SSD cache drive properly for your use case.

only if your use of the quicker cache drive requires higher than current cache drive capacity

its kernel functionality and as you already know with the S3 sleep plugin the sleep is possible and used by hundreds of users so it is well tested as well you understood nothing from this topic but that is your shame not mine we are in 2022 and it has been many many years since any modern filesystem does not get corrupted with dirty shutdowns. not during machine sleep. No car maker is going to call your car to the service once your oil light has come on for a second - inadequately assuming that your engine is corrupted - this is what unraid does today with our parity. wake up man you are full of nonsense this is about parity check not about data integrity on the filesystem. you probably do not understand the topic but your parity even when your servers are on UPS are not any cleaner than mine is after the dirty shutdown. you know the parity quality only after the finished check and since that moment you can have corrupted parity due to failing drive or memory module so you really need to get your stuff together before posting such BS

if you can afford smaller outages i would consider to build a parallel unraid server with 8 drives and copy it over

yes even ssd drives fail...