SpinRite on Synology Drives?

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

TAC

Member
Sep 28, 2020
6
0
I have a Synology NAS with four 8TB drive running SHR (1-drive fault tolerance) and want to test all the drives with SpinRite 6.1.

I figure the safest way would be to turn the Synology NAS off, pull one drive and test it on my Zima SBC. Then replace the drive in my Synology and power it back up and confrim the NAS is happy. I could repeat this on each of the four drives when I can afford to have the NAS offline.

Another (risky) option would be to pull a drive and leave the NAS running. After running SpinRite, reinstall the drive. I don't know if SpinRite corrected an error, if the Synology SHR system would have to rebuild the drive. Of course with this scenario if I had a problem with one of the three drives left in the system I'd be screwed.

A third option, which is proably not a good idea, would be to turn off the NAS and put two drives on my Zima SBC and run SpinRite. I think with this setup if SpinRite messed with both drives I'd loose all my data.
 
I think your thinking is correct. An 8TB drive is going to take about 4 hours to scan, assuming a level 2 read & recover pass across the drive. And we won't be getting multiple simultaneous drive support in SpinRite until v7. So pulling two at once doesn't buy you much. The trouble with bringing the NAS back up and using it during those 4 hours (each) that a drive missing is that the NAS's online data will continue to evolve while that drive is missing from the NAS. So that drive will fall out of sync and the NAS will need to be rebuilt. Depending upon how "smart" the NAS is, for an 8TB drive that could take a long time.

My best advice? ... would be to leave everything alone and not go looking for trouble. If a drive does report as troubled in the NAS, then it would be interesting to run SpinRite across it. But otherwise I'd leave well enough alone. :)
 
As an owner of multiple Synology systems: If you pull a drive while the system is operating, you will have broken the RAID, and it will need to be rebuilt when the drive is reinserted. Accordingly, do NOT pull a working drive from a RAID while the system is powered on... unless you are desperate to have no down time. Because all the disks stand a good chance of being the same brand and the same age, forcing an intensive rebuild risks one of the other disks failing during a rebuild, and then you've nothing unless you have a backup. (Which is the supposed point of RAID-6, with the possibility of a RAID surviving 2 failed disks.)

If you take the drives out while the NAS is powered off, make sure you only take out one at a time or else label them to put them back in the correct slot. If you run SpinRite on them, and allow it to write to the disks (repair something) then you will STILL have to run the built in data scrubbing if you expect the NAS to detect the changes.

So based on the fact that you're going to end up data scrubbing either way, unless you know you have a problem, what you should do is use the Synology's build in data scrubbing feature, as @magnificent_starfish suggested. It will do the same work SpinRite would so far as confirming the readability of the sectors, but it will take RAID checksumming into account, which SpinRite cannot do. You can even configure your NAS to do such a data scrub on a regular basis, so any problems hopefully get detected sooner than later.

Also, I have to note, as has been said many times before: RAID is NOT a backup. Have backups!!
 
An 8TB drive is going to take about 4 hours to scan, assuming a level 2 read & recover pass across the drive.
I think it will take 10-14 hours. It took 21 hours to do a Level 2 scan of my 16 TB drive at an average speed of 211 MB/s. An 8 TB will be a little slower than that. My empty 6 TB SMR drive did a Level 2 in 4 hours at an average speed of 398 MB/s.

16 TB:

6 TB:

If you want to look at more performance data:
 
@ColbyBouma : It would be interesting to have you — if you're interested — do a level 2 across the first half terabyte and the last half terabyte of those drives and share their extremes of performance. We know that one of the ways they are achieving such high densities is by pushing data storage further toward the hub than older drives, with correspondingly reduced transfer rates.
 
@ColbyBouma : It would be interesting to have you — if you're interested — do a level 2 across the first half terabyte and the last half terabyte of those drives and share their extremes of performance. We know that one of the ways they are achieving such high densities is by pushing data storage further toward the hub than older drives, with correspondingly reduced transfer rates.
Here's the benchmark from the 16 TB drive's log:
Code:
  |==========================================================================|
  |                          Performance Benchmarks                          |
  |--------------------------------------------------------------------------|
  |                    smart polling delay:  16.662 msec                     |
  |                    random sectors time:  11.965 msec                     |
  |                    front of drive rate: 267.154 MB/s                     |
  |                    midpoint drive rate: 240.226 MB/s                     |
  |                      end of drive rate: 127.704 MB/s                     |
  |==========================================================================|

Here's the empty 6 TB SMR drive. In case anyone reading this thread hasn't seen the discussions about SMR drives: when they're empty, their controller doesn't actually read the platters, it just returns 0's as fast as it can. This results in SSD-like speeds.
Code:
  |==========================================================================|
  |                          Performance Benchmarks                          |
  |--------------------------------------------------------------------------|
  |                    smart polling delay:  33.695 msec                     |
  |                    random sectors time:   0.525 msec                     |
  |                    front of drive rate: 397.075 MB/s                     |
  |                    midpoint drive rate: 397.619 MB/s                     |
  |                      end of drive rate: 398.952 MB/s                     |
  |==========================================================================|

An 8TB drive is going to take about 4 hours to scan
That would be around 555 MB/s. An SSD can do that, but definitely not a hard drive.
 
AH!! I've been splitting my attention too much and didn't pick up that your drives are SMR. Given that, as we know, all bets are off! :confused:
Only my 6 TB drive is SMR. I probably shouldn't have included it. I think I did because its scan time was close to 4 hours.

The point I was trying to make is that it will take a lot longer than 4 hours to scan an 8 TB HDD.
 
Yes, but wouldn't anyone in their right mind want to use SpiRite!
Not in this case, @TAC. If there's really a problem, then yes. And if you were willing to "down" your NAS for the duration, then okay. But the real trouble stems from your wanting to have the NAS up with a drive deliberately absent. There's no two ways around the fact that the result will be the need for a full rebuild. And given that the NAS is all about drive redundancy in the event of a failure, the need to run SpinRite over those drives is far far reduced... to the point that given the need to rebuild upon reinsertion, it really doesn't make any sense to do it. :confused:
 
full rebuild
Just to further clarify what @Steve said: The only way to remove a drive for "maintenance" is to do so while the system is fully powered off so that all logging and journalling is disabled. If you pop your drive out with the NAS powered on, even for just a second, then immediately put it back in... it will STILL have to do a FULL REBUILD.
 
  • Like
Reactions: SeanBZA
First time poster, dusting off this old thread to add my current experience; I just purchased SR6.1 to attempt maintenance of a 14TB Proxmox cluster stored across a 2 Drive SHR-1 array on a Synology RS1619.

The cluster is all shutdown of course, as is the Synology - And I've started with one drive of the array on level 3.
Currently SR is reporting 38 Hours to completion.

Once finished the plan is to reintroduce the drive into the Array, power the Synology back up to let it normalize, then rinse & repeat with the other drive.

I didn't anticipate the total duration of downtime going in, but here we are.