resinch a dieing disk or add new disk & resinch?

berillio wrote:
Just to clarify, what is the difference between: Volume Scan Re-synch RAID Rebuild

A volume scan looks at the ext file system, and checks the directory structures and metadata for consistency. If it finds inconsistencies, it tries to correct them. If there are no consistencies, then nothing is changed.

A resync looks at the RAID level. One of the the disks is being resync'ed with the others, using the raid redundancy to compute the contents of that disk from the others.. That means that each block on that disk is being rewritten. If there are bad sectors on that disk, the process fails.

Resync and Rebuild are the same.

berillio wrote:
and what would I need, to end up without (if possible) any data loss, like it was 15h ago?

The NAS thinks one disk has failed. If the others are intact, the NAS should boot up without it, and give you access to all the files. But the volume will be degraded. So there is no possibility of resync - the device to be synced is not present. A volume scan will be done though, and that could result in some data loss.

If you then hot-insert your replacement drive, a resync will occur.

I wouldn't reinsert the original disk just yet, since your test results are inconclusive.

Hi Stephen, I did not disappear without even thanking you for your help and patience.
The whole of yesterday I downloaded countless versions of Seatools for Windows, (1.0.2.10, 1.0.2.08, 1.0.2.06) from different sites (Seagate, MajorGeeks, Download.com, SouceForge), using different PCs (the one I was using yesterday as well as the netbook).
They ALL failed to install.
So far, Seatools for Windows is the only soft which I have not been able to use. As one pc was "temperamental", I used its SATA cabling to wire the HD up in the pc I was using yesterday, but Seatools for DOS (from the Hiren Disk) still crashed out, half way through the checking. Hiren has the DOS/graphical and the DOS/command line, tried both, no joy. Last thing, I tried I run Victoria (vers 4.46b, 12-08-2008) again to read the blocks individually. This test is still (fingers crossed) running, after 10 h has done ~47%. It has issued a warning for a "Slow block (297ms access time).
If you aren't familiar with Victoria (I wasn't), I found this link
http://hardware-today.com/articles/hdds ... dd_repairs

quite useful. Note that, although it is the same version, my default values (for organising /presenting the read speed results) are different from mine, which are 5, 20, 50, 200, 600 (ms).

While writing these notes, Victoria stopped, soft still responding. So I will resume it later on.
I also downloaded the ISO for Seatools for DOS, and I am going to run it and see if it sheds any light on this HD. It will run in Freedos, so the pc won't be online, but not wishing to have issues with failing PSU on the other PC, I will run it here, I can follow the forum from the netbook

Guess what.. it does not run either. It creates the C:RAM drive, but while copying files it run out of space (for info, that PC is an Athlon 64 with 2Gb of RAM).
I think that I try to burn the iso of a newer version of Hiren (15.2, not 14.0) to see if the software onboard run any better.

Can you please suggest any other RELIABLE testing software which I could use? I am running out of options (although Victoria got me somewhere).

Many thanks, Berillio

Seatools has always been reliable for me (as has lifeguard). It has sometimes gone non-responsive with disks that turned out to be bad, but I haven't had it do that for good disks.

Good afternoon Stephen,
Hurrayyyy
I eventually managed to run Seatools for DOS (graphical), off another Hiren disk (I have many versions/copies).
Long Test PASSED
Run it again, PASSED it again.

Seatools has always been reliable for me (as has lifeguard)

Lifeguard had already passed it, first time around.

Basically all tests run with all softares were passed, WITH THE EXCEPTION OF VICTORIA, which finds a block which is too slow >1000ms and it flags it as an error. I rerun the Victoria test just on the area of that block, and identified the same block, twice. I am currently re-testing the entire disk, with Victoria off the other CD, as yesterday Victoria twice stopped at 49.2% execution time (and 98%, when I restarted it half way thru' - I feel that this is somewhat unrelated).

Victoria can "remap" the offending block (which I would do unless you advice me not to do - not sure how these things are dealt).

Whether I remap the block or not, considering that both Seatools and Lifeguard don't find any fault, I imagine that I could refit the disk in bay1 (its original place). NAS should then re-synching the whole lot, and hopefully let me access everything again.
I do not know if then the "Disk fail" flag will be removed (but kept it in the logs), or the volume will be considered to be "degraded" forever. If so, what should I do? I have another identical HD ready to go in bay 4, I only wish to know when it is the best time to fit it, and how to maximise my volume, expecially considering that, after all the testing, we should be reasonably comfortable with HD1.
Thanks again, berillio

If you have an identical disk ready to go, then just hot-insert it into the NAS (replacing the failed disk). Personally I run the vendor diags before insertion, but that is up to you.

A > 1000 ms read time is certainly not healthy, no matter what seatools/lifeguard say. Though remapping data blocks also can hurt performance, since it forces more seeks. What you could do with HD1 is run the destructive write Seatools test. This often finds errors that the non-destructive tests miss, and also returns the drive to an unformatted state.

?? your replied never showed up!

Sorry Stephen,
Your replied only showed up today (31st), while I pasting a new post. For the last week I was refreshing the page few times every day, with no changes.
AHHH it was on the next page ! Shuck, wasted one week, I was awaiting for a reply on those two queries before doing something which may be wrong. .

Personally I run the vendor diags before insertion, but that is up to you.

I'll do that now.

I am under the impression that, notwithstanding the "Pass" from Seatools and Lifeguard, you are convinced that HD1 is utterly faulty (well, NAS flagged it as "fail"). Which is why you are suggesting the "destructive Seatools test" which could "tick out" the offending block, and return it to the unformatted state (this is in my "option 2").
I am more concerned by the potential data loss.
Is hot-inserting immediately the new disk in bay 4 (before the Volume Scan) going to be safer than my option 2 or option 3 below ?

Also, before I do anything, could it be valuable to empty bay 2 and bay 3, boot up NAS without any disk (to avoid a Volume scan and potential data loss), just to read the log to see if there is more info in that log? I remember reading "disk fail" and nothing else, but maybe that was only a label and there are more infos somewhere else (where, or how to read it?).

To recap, I could
Option 1 - (your suggestion)
a) hot-insert the new replacing disk (in bay1 or bay4, or it is immaterial? I'd prefer bay4, so the bay order matches the HD age)
b) Resinch
c) destructive test/reformat HD1
d) hot-insert HD1 causing another resynch
This way the first resynch is done using data from only two disks (compromised volume, potential data loss?).

Option 2
a) remap the block (to avoid NAS flagging a slow disk),
b) refit HD1 in bay1 and add HD4 in bay4 at the same time. NAS will resynch (volume NOT compromised, albeit needing a resinch, so no data loss?)
c) Switch off NAS, remove HD1 in bay 1, run Seatools destructive test /reformatting.
d) reboot NAS and hot-insert HD1 back. NAS will re-sinch again (but volume was compromised by HD removal, so potential data loss?).
Doing this way all the resynching is done on 4 disks, with data always availlable on 3 disks; the first time the volume is not compromised, the second time the volume is compromised, but the data is spread more thinly across the 4 disks.

Option 3
a) remap the block, (to avoid NAS flagging a slow disk)
b) refit HD1 in bay1, NAS will resynch (with no data loss)
c) after resynch, hot insert HD4 in Bay 4, resynch again to increase the size of the volume

Done ! Do not reformat HD1, as the bad block has been remapped. But this may cause loss of performance (extra seeking?)

Which one could be the safer for the data, and in the long run ?

Many thanks in advance, sorry for being incommunicado for a week, berillio

berillio wrote:
I am under the impression that, notwithstanding the "Pass" from Seatools and Lifeguard, you are convinced that HD1 is utterly faulty (well, NAS flagged it as "fail"). Which is why you are suggesting the "destructive Seatools test" which could "tick out" the offending block...

I've had drives that pass the non-destructive tests, but which fail horribly on the destructive write test. Not sure if that is your situation, but I am suspicious that a single block would fail with a > 1 sec read timeout, but nothing else wrong.

The NAS expects disk replacements to be inserted into the original slot. So I wouldn't insert the next disk into bay 4.

For option (2) and (3) - are you meaning to insert the disks with the NAS off on step (b)? Or a hot insert?

Regarding HD1. During this week I have noticed that Victoria (running on MiniXP, from a boot-up disk/flash card) would give warnings of slow blocks (200<300ms) at varying locations (the location would differ from scan to scan), and would flag one error consistently at one LBA. But when I tried to run an "installed" copy of Victoria on the PC which was running XP as normal, I had no errors. Likewise, if I also boot up into XP and did not run the "installed" Victoria, but another copy off the memory stick or SD card, I have no error. But if I run again the MiniXP off the boot-up CD/DVD/memstic/flashcard, and run Victoria, I get the error.
In all cases, it is the same version of Victoria, same version build etc.
I can only guess that the driver which run the hard disks are better under Windows than under the MiniXP.
Which tells me that the HD fault is somewhat even smaller. Nevertheless, minute as it maybe , there is a weakness in that disk, which needs to be addressed.
This is the reason why I think that remapping the block could be enough to solve the issue which NAS flagged (as in my Option 3).

Your query
Both Option 2 and Option 3, HD1 refitted BEFORE restarting NAS.
I interrupted NAS while it was starting a resinch, so I assume that when I restart NAS, and it finds HD1 in bay1, it would restart that resinch (which had been interrupted after one minute or maybe two minutes maximum).
So, for Option 2, it may be immaterial if HD4 was present already (meaning been inserted when NAS was off) or hot-inserted, which would call for a resinch, but then that may simply interrupt a resinch which started one minute earlier and restart it (is it? see last paragraph).

In Option 3, I was considering waiting until NAS had finished the resinch (and hopefully found no error), then hot-insert HD4 to increase volume size, which would call for a resinch on 4 disks.
.
If my thinking for Option 2 is wrong, and NAS would instead finish the first resinch of HD1, 2 & 3(ignoring the hot-insert), and then, once the resinch has finished, resinch the 4 HDs together, then Option 2 (a+b) and 3 (a+b+c) would actually be the same thing. Which means that, to do Option 2 as I am considering, I would need to refit both HD1 and HD4 before powering NAS, which should then restart the resinch which was interrupted, but seeing a 4th disk, would span the resinch across all disks (again, I am just speculating/guessing what NAS would do)
Sorry if it all sound messy and convoluted, I am sure that it is all very simple, but I probably have not yet understood the laws of NAS as yet.

Run SeaTools and Lifeguard on HD4 - both passed OK (but then so did HD1)
Should I run the Destructive test - Reformat on HD4 (never used) making totally sure that it is OK?