Gilbert

try to check these 3 disks on another machine to make sure it's a disk error, if yes follow the steps in manual.

btw, i checked the access to the files is properly granted.

I use snapraid status and found there are 81 files with a zero sub-second timestamp issue, and run 'snapraid touch' to fix. the reuslt is nothing changed and the error still there. There is no problem to sync and access these files, any comments?

I choose to save the snapraid.content to /home/user/ to avoid using sudo to run snapraid.

from your previous post, the mount point /mnt/parity changed from 3.7TB disk to 2.7TB, I think this is the root cause. you'd better use the UUID to mount disks, like /dev/disk/by-uuid/ee9298c7-0006-499d-9e30-34ca54b9993f /mnt/parity ext4 defaults 0 0

You are right, nice to have parity disks larger than data disks, it's much safer for SYNC. while 16TB parity for 14TB data disks is not cost effective, i will choose to use mkfs.ext4 -m 5 to format the largest data disk and leave minfreespace=50G unchanged. for parity disk formatting i run "mkfs.ext4 -m 0 -J size=4 -i 67108864 DEVICE", it's working good and the parity size is only about 100GB larger than any single data disk. Filesystem Size Used Avail Use% Mounted on tmpfs 38G 21M 38G 1% /run efivarfs...

I'm now understanding how parity works and why parity disk must be no less than the largest disk in the array. i do recommend snapraid+mergerfs for home data storage. lvm requires all the disks move all together, and mergerfs can move one each time.

I'm now understanding how parity works and why parity disk must be no less than the largest disk in the array. i do recommend snapraid+mergerfs for home data storage.