January 9, 20188 yr Author On 03/01/2018 at 9:44 AM, johnnie.black said: They'd need to be created before the problem, btrfs creates them automatically on write, with xfs you'd need an external utility to create them manually, by using the Dynamix file integrity plugin or corz for example. Well I am currently in the process of copying all the data from disk 5 across to the server - it's taking time due to work and family issues but I am nearly there. Then I can look at the Dynamix plugin and see what I can do regarding checksums and disk 11
January 9, 20188 yr Community Expert Since you seemed to be unaware of the problems with the actual disk SMART, I have to ask whether or not you have configured Notifications. unRAID will notify by email or other method when you have SMART issues. Notifications is especially important to you due to the number of disks you have. As you upsize disks, you might consider reducing the number of disks. Fewer disks means fewer opportunities for these sorts of problems.
January 9, 20188 yr Author 2 hours ago, trurl said: Since you seemed to be unaware of the problems with the actual disk SMART, I have to ask whether or not you have configured Notifications. unRAID will notify by email or other method when you have SMART issues. Notifications is especially important to you due to the number of disks you have. As you upsize disks, you might consider reducing the number of disks. Fewer disks means fewer opportunities for these sorts of problems. Now that you mention it - I have configured notifications - I do get emails through with the various test results etc and parity checks and array healthy messages were all coming back as positives - up until the last set of issues. Although, I am now thinking that a cable loosening (that started it all) may in fact be attributable to my nearly 2 year old and the fact that the server is in the lounge and he loves to climb...which will all be resolved in the next week or so when I remove the SATA cables entirely for the new case in the new workshop/garage location...
January 10, 20188 yr We really need to stop advising users to rebuild on top of a drive that gets kicked from the array. Too high a risk for another disk to drop (due to cabling or other issues) and cause a corrupted rebuild. And this use case is repeating entirely too frequently. The rebuild should be to a fresh disk, and its it falls, the original disk that was kicked should be used as the source of truth. If new files were written to the disk after it was kicked, you can try to repair the rebuilt drive and used to harvest just the newly added files. Such files would need to be tested to see if they are valid.
January 11, 20188 yr Author On 10/01/2018 at 4:59 AM, SSD said: We really need to stop advising users to rebuild on top of a drive that gets kicked from the array. Too high a risk for another disk to drop (due to cabling or other issues) and cause a corrupted rebuild. And this use case is repeating entirely too frequently. The rebuild should be to a fresh disk, and its it falls, the original disk that was kicked should be used as the source of truth. If new files were written to the disk after it was kicked, you can try to repair the rebuilt drive and used to harvest just the newly added files. Such files would need to be tested to see if they are valid. Now that is a much better idea! Too late for me in this instance, but definitely should be the way forward.
Archived
This topic is now archived and is closed to further replies.