This recent post by
@SecretStasher
SpinRite 6.1 penetrating RAID?
nudged me into posing this related question of my own, below.
I wonder whether we can always safely 'repair' a drive that has been temporarily extracted from a RAID array, and then reintroduce the repaired drive into the same array without allowing - or expecting? - the RAID controller to trigger an array resilvering?
(Taking care in the above scenario to power-down/up the controller+drives etc. as appropriate. I'm not referring here to hot-swap drive situations.)
I know we are also not considering SCSI based RAID setups here on this Forum, but I still vividly recall (while I was maintaining Novell servers many moons ago) how absolutely unforgiving our company's Adaptec SCSI (hardware) RAID controllers were to any changes being made to the contents of their installed drives, while they - the controllers - weren't 'in control' of the drives.
If any 'outside-of-the-RAID' change was made to any part of any one of the drives then the whole RAID array would fail to mount or would fail to auto-rebuild.
So with today's SATA based controllers, I'm curious about how tolerant they actually are to changes that might be made 'off line' to one or more of the drives in an array; for example changes that Spinrite might make to a drive if we ask it (Spinrite) to go ahead and repair/refresh/recover one or more sector(s) on any single drive from an array?
Before I pose my two specific questions (labelled 1 and 2 at the end) I'll offer a hypothetical scenario with five assumptions in these paragraphs below, labelled A to E.
Please jump to the end of this post if you're in a hurry
Assumption A.
My hypothetical RAID array appears to be functioning normally, and my RAID controller has successfully coped with, and has 'internally' corrected, one or more (let's say) transient disk-read errors.
Assumption B.
While running normally, my RAID controller with its sophisticated RAID algorithms, had maintained the live array's overall integrity by (re)calculating on-the-fly, and then also storing, the parity (or the checksums) of the data that was read from and written to the array's discrete drives.
Assumption C.
I decide to run Spinrite 6 on all of the drives in the array, so I arrange a tidy shut-down of the computer and its RAID controller and extract each physical drive in turn to be installed temporarily into my dedicated Spinrite computer.
Assumption D.
While Spinrite is running on my individual RAID drives, it finds and fixes at least one bad sector. In other words, Spinrite 'nudges' that particular drive to remap the bad sector(s) to the drive's still-good reserve sector(s).
Assumption E.
I then reassemble and power-up my RAID array using those same Spinrite-scanned drives.
Here are my questions:
Question 1:
Will every RAID controller on today's market tolerate and accomodate the remapping of sectors on one or more of its drives if that sector-remapping occurred while the drives were not being 'live-maintained', on-the-fly by that controller, along with its probably fine-tuned RAID/parity algorithms?
Question 2:
Wouldn't it be wise or might it even be necessary with some controllers to run Spinrite on one drive at a time, then - for any drive on which Spinrite signalled an 'R' ('Repaired') - to then reassemble the RAID array and allow (or trigger?) the controller to run a full re-silvering - i.e. to recalculating the array's overall parity / sumcheck tables etc. -
before repeating the Spinrite cycle on the other drive(s)?
I'd welcome your thoughts on this? Or perhaps some informed insights on how tolerant the current, SATA-based RAID controllers (hardware
or software RAID controllers) are to 'external' changes to the sector geometry on their individual drives?
In my case, given that I don't know the answer to my own Question 1, my strong instinct would be to answer YES to Question 2.
In other words I would subject only one of my RAID drives at a time to a Spinrite scan, and I'd wait - each time I reassembled the array - to see if my RAID controller deemed it necessary to trigger an array resilvering. Just to be maximally prudent.
Colin P. (A different Colin P.)