NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Can you safely stop as re-sync?
While I've successfully halted the re-sync that happens as a part of the ReadyNAS scrub (by echoing idle to the appropriate array's sync_action), I now find myself in a position that has caused other...
StephenB : So if the data on one of the other drives is corrupt, it won't try to recover from the rest of the array, including the drive it is re-syncing, even though the status is shown as "re-syncing", not "re-building" and the performance page only shows reads except during the period it ran the backups? Will it at least give me some kind of error that there is a parity issue? It may end up a moot point. The completion estimate updated and it should complete before the replacement drive gets here and I can run it through some tests. The drives are all "low mileage", so no issue with the stress. This is a new situation for me. I typically replace drives before they create this kind of issue. And the couple I haven't have all died completely -- no re-sync attempted.
ranaabid : This is my backup, and I'm trying to avoid the need to do a data recovery, which I can do from my (RAID6) primary NAS if needed. It'll just take a few days, during which I'll have no backup of the data not also backed up off-site. I only back up critical data off-site, and this backup includes all of my media files, which are obviously non-critical.
Sandshark wrote:
So if the data on one of the other drives is corrupt, it won't try to recover from the rest of the array, including the drive it is re-syncing, even though the status is shown as "re-syncing", not "re-building" and the performance page only shows reads except during the period it ran the backups?
With RAID 5/6 the mdadm resync assumes the data blocks are ok unless there is a read error. I believe it only re-writes parity blocks when it finds a discrepancy with no read error. That would expain the lack of writes.
If enabled, Netgear's bit-rot protection should also kick in if there is an error in the file checksums, but that would only happen when the file is read later on (not by mdadm of course, since it is running below BTRFS).
Not sure how that changes the calculus on whether you should pull the disk with errors now, or whether you should wait. I guess if data is wrong on the disk that dropped out (but the parity block was calculated on the correct data), then updating the parity blocks would lock in the error.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
