SpinRite on Synology Drives?

[TAC]

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.

 

[Steve]

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.

 

[PHolder]

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!!

 

[Steve]

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.

Ah, right! That's a very good point, Paul!

 

[ColbyBouma]

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.1 Alpha/Colby Bouma/390.LOG · main · GRC Community / SpinRite Logs · GitLab

A community collection of logs from SpinRite. https://www.grc.com/sr/spinrite.htm

gitlab.com

6 TB:

6.1 Alpha/Colby Bouma/400.LOG · main · GRC Community / SpinRite Logs · GitLab

A community collection of logs from SpinRite. https://www.grc.com/sr/spinrite.htm

gitlab.com

If you want to look at more performance data:

https://gitlab.com/api/v4/projects/42722961/jobs/artifacts/main/raw/Logs.csv?job=build-job

 

[Steve]

@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]

@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:

  |==========================================================================|
  |                          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.

  |==========================================================================|
  |                          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.

 

[Steve]

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!

 

[ColbyBouma]

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!

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.

 

[Steve]

The point I was trying to make is that it will take a lot longer than 4 hours to scan an 8 TB HDD.

Was it SSDs that I've been thinking of at half a terabyte per hour? Maybe that's what's confusing me. Thanks!

 

[ColbyBouma]

Was it SSDs that I've been thinking of at half a terabyte per hour? Maybe that's what's confusing me. Thanks!

0.5 TB/hr would be 16 hours for an 8 TB drive, not 4 hours

 

[Steve]

0.5 TB/hr would be 16 hours for an 8 TB drive, not 4 hours

To quote Homer Simpson: Doh!!!

 

[TAC]

Doesn't the NAS itself offer some kind of data scrubbing feature?

Yes, but wouldn't anyone in their right mind want to use SpiRite!

 

[Steve]

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.

 

[PHolder]

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.

 

[TheOfficialWilson]

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.

 

[PHolder]

attempt maintenance

Synology offers it's own [RAID} volume maintenance while keeping it online. Unless you are seeing SMART error reports or something, I would have stuck with letting the Synology run its own audits.