I'll start off by saying that I have been negligent. I run a diff and sync script nightly, but I haven't actually checked the logs in quite some time, and I didn't notice that the parity file has grown so big that the disk is full. I have no idea how long it has been since a sync was successfully run, but in the meantime I have done a huge amount of file operations, using exiftool to rename my entire photo and video catalog. When I run snapraid check, I get a lot of errors, many of them "unrecoverable".
My configuration is: I have four disks total, one of them (the largest) is a parity disk. I know I'm living on the edge, but everything valuable to me on this server is in cloud storage as well. That said, I'd prefer not to have to deal with a big loss of data. I do mean to add more disks eventually.
I'm assuming that the best way to deal with this would be to remove the parity file and do a fresh sync. Would snapraid sync -F be advised in this situation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I posted a reply that my parity disk wasn't my largest, but realized I was wrong about that. There are two disks of the same size, but for some reason df is reporting one of them is smaller than it is supposed to be.
Output from lsblk
sdb 8:16 0 2.7T 0 disk /mnt/disk1
sdc 8:32 0 3.7T 0 disk /mnt/disk2
sdd 8:48 0 2.7T 0 disk /mnt/disk0
sde 8:64 0 3.7T 0 disk /mnt/parity
I read a few other topics about this error on here, but none seem to apply to my case. For more info my disks are formatted ext4, mergerfs is used to pool the array, and I'm using a very old version of Debian as the OS (which is one reason I'm trying to sort all of this out - so I can upgrade.
I guess I have determined that this isn't really a SnapRAID issue, though, so I'll figure what I did wrong when setting up the parity disk.
Last edit: Josh 2024-04-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is why I don't use scripts with my precious, precious data. But that's just me.
As for the rest of your problem, the outofparity error is because your parity drive is too small, it should be at least equal or greater than you largest data disk.
Not sure what went wrong there, but you were guaranteed to run into problems with that setup.
I suggest you read the manual, especiall section 7.8 blocksize SIZE_IN_KIBIBYTES to give yourself an idea of how big the parity disk should be or how much data you will need to hold back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'll start off by saying that I have been negligent. I run a diff and sync script nightly, but I haven't actually checked the logs in quite some time, and I didn't notice that the parity file has grown so big that the disk is full. I have no idea how long it has been since a sync was successfully run, but in the meantime I have done a huge amount of file operations, using exiftool to rename my entire photo and video catalog. When I run
snapraid check, I get a lot of errors, many of them "unrecoverable".My configuration is: I have four disks total, one of them (the largest) is a parity disk. I know I'm living on the edge, but everything valuable to me on this server is in cloud storage as well. That said, I'd prefer not to have to deal with a big loss of data. I do mean to add more disks eventually.
I'm assuming that the best way to deal with this would be to remove the parity file and do a fresh sync. Would
snapraid sync -Fbe advised in this situation.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
I posted a reply that my parity disk wasn't my largest, but realized I was wrong about that. There are two disks of the same size, but for some reason
dfis reporting one of them is smaller than it is supposed to be.Output from
lsblkOutput of
df -h:I read a few other topics about this error on here, but none seem to apply to my case. For more info my disks are formatted ext4, mergerfs is used to pool the array, and I'm using a very old version of Debian as the OS (which is one reason I'm trying to sort all of this out - so I can upgrade.
I guess I have determined that this isn't really a SnapRAID issue, though, so I'll figure what I did wrong when setting up the parity disk.
Last edit: Josh 2024-04-01
This is why I don't use scripts with my precious, precious data. But that's just me.
As for the rest of your problem, the outofparity error is because your parity drive is too small, it should be at least equal or greater than you largest data disk.
Not sure what went wrong there, but you were guaranteed to run into problems with that setup.
I suggest you read the manual, especiall section 7.8 blocksize SIZE_IN_KIBIBYTES to give yourself an idea of how big the parity disk should be or how much data you will need to hold back.