Mover wont move appdata and system files and gets errors

[desertfox_0815]

hey guys,

 

my unraid server is driving me nuts...

My server consists of an amd ryzen 3200g cpu, asus b450m-a2 mb, 8gb of ram and 1 8TB parity disk and 7 data disks (6x 4tb, 1x 8tb) on xfs filesystem. cache is on 2 1tb samsung ssds with raid0 and btrfs.

 

i want to free my cache completly cause my newly copied files arent moved to the array.

 

this is my log screenshot when running mover.

 

Please help me. if recreating unraid in total is the way i will do so as long as my array data will persist. parity can be recreated without problems. parity check last night went through without sync errors

 

[JorgeB]

Those are checksum errors, it means data is getting corrupt, please post the diagnostics: Tools -> Diagnostics

[trurl]

You should keep appdata, domains, and system shares on cache so your dockers and VMs will perform better and not keep array spunup. 

 

Will see what what Diagnostics says about your hardware issue and how you other settings are. 

[desertfox_0815]

thanks for the fast replys. 

i'Ve attached diagnostics.

 

i've already removed some old folders under appdata.

normally appdata and system is on cache with "prefer" here.

i've moved them due to the checksum errors.

 

Also i've removed cache drives from config after beeing empty after mover.

reconfigured cache with raid0 and btrfs but still getting errors.

tower-diagnostics-20210128-1116.zip

[desertfox_0815]

Do you guys thing its possible that one of my ssds in cache is the problem`?

i've deconfigured the samsung 860evo ssd and only configured the 870evo.

no checksum error with data on cache so far and no problems while moving them to array

[desertfox_0815]

Ok, errors still exist. 

copied a 28Gb testfile onto my array/cache. 

Scrub is still finding uncorrectable errors

[JorgeB]

Data corruption and lots of segfaulting suggest a hardware issue, start by running memtest.

[desertfox_0815]

Memtest showed that the newly ordered ram stick was faulty from 1728mb.

Checked both sticks together in both slots and each stick in both slots. 

One stick is dead and will be changed thanks to amazon prime 🙂

 

Running unraid with the good stick did result in good data when scubbing the data newly copied to cache.

 

do i need to check something else, will parity check be enough to check data consitency?

[itimpi]

7 minutes ago, desertfox_0815 said:

o i need to check something else, will parity check be enough to check data consitency?

A parity check will confirm that parity calculations are correct for the data sectors stored on the drives.    It will not check that the data is not already corrupt. 

[desertfox_0815]

Just now, itimpi said:

A parity check will confirm that parity calculations are correct for the data sectors stored on the drives.    It will not check that the data is not already corrupt. 

 

Is there a way for me to check this?!

[itimpi]

5 minutes ago, desertfox_0815 said:

 

Is there a way for me to check this?!

You have to have checksums for the data in question.   If the file system is btrfs then checksums are built in for that format.  For XFS you have to explicitly run a process that generates the checksums.  This process needs to run before any corruption can occur.   The File Integrity plug-in can help automate building checksums for xfs.

 

[desertfox_0815]

ok, my cache pool is btrfs and the problematic ramstick was in the system for 2 days.

i've not copied any new files onto the server since then because i've noticed the "cache pool problem".

So should be fine.

 

Thanks alot