Hello all,

Got a problem here;
I have four exact and pretty much brand new SATA2 2TB Samsung Green HDDs, they are all connected to the motherboard, win2008 can find them, and they are all showing in Disk Management.

I make a RAID-5 out of these four with one redundancy disk (total space 6TB), all seems working nicely. When it starts formatting, every time it stops (tried about 5 times now) at 3%, and always the same disk shows 'Errors'. Reading the Microsoft pages, this means I/O errors (no idea what it means at a technical level, but that's not important for me atm).

I conclude that that disc is corrupt, and I better change it with another new disk, before I put all my important files on it.

The silly problem is; how do I know which hard disk in my pc is the one thats failing ? The Disk Management only shows Disk 1, Disk 2, Disk 3. Other tools show the Disk Serial as well, but not within Disk Management, neither even when you right click and goto properties and search among the combo box. The serial is useful, because it's printed on top of the physical HDD. But how do I determine and take out a HDD, and be absolutely sure, that that is the failing HDD ?

Before anyone asks, they all show up as SAMSUNG HD204UI when you go to Volume Properties.

I dont believe Windows tells you, not that I have seen anyway, best to use an application such as Victoria or HDDScan to find it out, almost positive they will tell you.

When working with RAID's I usually fire up R-Studio and it lists all serial numbers for connected drives, the demo will also do this if you do not wish to purchase a license.

_________________
Secarma Ltd
http://www.secarma.co.uk

@uncleflo:

I agree with CraigL that something like HDDScan will answer your question of giving you the disk s/n (there are other utilities which would also do this), and then you can use the "read" function of HDDScan to cause I/O to each disk, one at a time, to help you with identification if needed.

However...


Actually, the type of problem is important, if you want to properly identify and then resolve whatever problem you have. If you wrongly diagnose the problem (or don't do any diagnosis), then you may not resolve the problem - or you might think you have solved it, and later find out that you haven't...


You can't be sure of that conclusion. Ignoring the use of "corrupt" for a moment (which is ambiguous/meaningless in this context), this is not necessarily a disk problem, and could instead be a problem with other parts.

If I was in your position, I would be checking the Windows System Event Log as a minimum, to see what events are being logged, at the time when you see errors during formatting - that's just a starting point. Further diagnosis might then need to be done (including possibly further use of HDDScan), depending on what events were being logged. Your comments about the type of problem not being important, suggest to me that you're not very technical (no offense), and so you might want to get someone more technical involved, if you really want to understand (and therefore to properly solve) your problem.

It's your data, your problem, your risk, so your decision Good luck with whatever you decide, even if you don't take my advice to avoid guessing at the cause...

Your feedback and suggestions are very welcome; and yes I do consider myself not very technical either. I'll post my findings on here about the error, and see if you could suggest anything useful.

I downloaded this HDD Scan application, it shows the disks fine, with all the info and serial numbers. But it doesn't let me run tasks on them, unless I change the End LBA to 2*10^9. Running a Surface Task, Read with:
Start LBA 0
End LBA 3907029168
Block Size 256
Gives me a "Error Input parameters, disk". What does LBA mean? What would be the max allowable number for my disk? And how long will a RD-Read task take? My Disks are all a SAMSUNG HD204UI

Looking at the Diagnostics/Event Viewer/Windows Logs/System, there seem to be three Errors popping up around that time.

Error
12:41:13
The device, \Device\Ide\iaStor0, did not respond within the timeout period.
Log Name: System
Source: iaStor
Event ID: 9

Information
12:41:16
Application popup: Windows - FT Orphaning: A disk that is part of a fault-tolerant volume can no longer be accessed.
Log Name: System
Source: Application Popup
Event ID: 26

Error
12:41:15
The device, \Device\Ide\iaStor0, did not respond within the timeout period.
Log Name: System
Source: iaStor
Event ID: 9

Error
12:41:16
The device, \Device\Ide\iaStor0, did not respond within the timeout period.
Log Name: System
Source: iaStor
Event ID: 9

I'm not guaranteeing to have time to help with your problem, but I'll give some comments below, based on this new info.


Good, so that's answered your original question.


That's not normal, but since you're talking about "them", it isn't a behaviour only seen with the "suspect" disk, so it isn't part of the current problem. I suspect this might be related to your HBA config, but I don't have time to try to diagnose this remotely.



Unfortunately the Event ID 9 entries, which are indeed a problem, are not specific enough to identify whether the problem is with the disk, SATA cable, motherboard SATA port, or power etc. Obviously depending on time, config, availability of spare parts, expertise, etc. you have choices about how to troubleshoot the cause of those messages (which then leads to the Event ID 26).

Perhaps the easiest way of troubleshooting (if this makes sense for your config) is to swap that drive to a different SATA port, different SATA cable, different power cable, and see if that drive is still the one where Windows reports errors i.e. does the problem follow the disk, even if everything else has been changed.

Or you could create a RAID 5 out of the other 3 disks, format it, and if that is successful (as expected) then delete this RAID volume, replace one of those 3 disks with the "suspect" disk (make NO other changes), repeat the process, and see if that formatting fails. If so, since the only thing you've changed is the disk in that situation, the problem must be the disk and not any of the other parts that I mentioned.

Other troubleshootin approaches are also possible, but those are some suggestions.

Good luck

LBA = Logical Block Address = sector

HDDScan is reporting the total capacity of the drive as 3907029169 LBAs. That's a little over 2TB.

3 907 029 169 x 512 = 2 000 398 934 528

You have restricted the drive size to about 1TB.

2 * (10^9) x 512 = 1 024 000 000 000

I suspect you could increase the capacity to 1TiB (= 2^40 = 1 099 511 627 776).

To do this, you would select a max LBA of ...

(2^40) / 512 - 1 = 2 147 483 647

If this works, then your setup would appear to have a 1TiB limit. Such limits are often due to problems with the chipset driver. NVIDIA's NForce drivers are one such example. A driver update fixes this problem. I don't know if Intel's drivers (iaStor.sys) have a similar issue, though.

_________________
A backup a day keeps DR away.

If HDDScan returns a Code 5 error message in the middle of a RD-Read Surface Scan of one of my disks, what does that mean? As well, the program crashes shortly after that.

I want to try out this suggested testing method to create a RAID 5 with three disks; But if I try this out under Windows Disk Management, I won't know the serial. Is there another program to create Raids and shows the serials so I can test this with?

My disk is supposed to be 2 Terrabytes (I think this is 2*1000^3 rather than 2*1024^3). Not being a math geek, how much would be my max LBA with a block size of 256, to put this into the program?

Finally, I should thank you guys for telling me all this. All of this testing is dead-slow and takes hours to test these disks one by one, but your comments have been and still are helpful.

Some comments below...


I don't know exactly what that means - perhaps other members will.

Does this occur with only one disk from the four?

Does it always occur at the same point on the disk?

Did you check the Windows system event log for that specific date/time? Does it contain a similar Event Code 9 entry as you reported before? If so, then HDDScan may be just reacting to an underlying problem (h/w or drivers, as suggested before).


That troubleshooting strategy which I suggested, does not rely on you seeing disk s/n in Windows - it just relies on you seeing success or failure when using different disks where you know whether you are using the disk which you believed to be "suspect", or not.


Disk LBAs do not get calculated in groups of 256. I guess you are seeing that HDDScan does I/Os in groups of 256 sectors (i.e. a 256 sector I/O size). That has no relation to the max LBA, which is just the number of sectors on the disk. As fzabkar said, your disk has max LBA of 3907029168.

I'm concerned that you say HDDScan is not working correctly unless you limit the size of each disk, but since that isn't specific to one disk, then it does not seem to be related to your initial problem. Previously fzabkar has already given you a hypothesis for what may be the cause.

Also, since you say the RAID creation fails at 3%, then this is likely to be near the start of the RAID volume. In some cases, the Windows Event entry includes the LBA of the detected problem, but it can require further investigation to determine this.

Another approach for seeing if any of your 4 disks is logging internal problems, would be to delete any RAID volume so that Windows sees them individually, and then use Smartmontools to collect both the internal SMART counters and its internal SMART Error Log.


You're welcome - and yes, diagnosis can unfortunately take a long time. Remote diagnosis even more so... Good luck

I should add that I would also choose a max LBA just over the 1TiB limit, ie 2 147 483 648.

_________________
A backup a day keeps DR away.

Code 5 means : Access is denied
I doubt it would be helpful though

Are you using HDDScan 3.3 revision?

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

No, I'm using HDDScan 3.1 . The 'Acess is denied' is correct from what I remember. But I wasn't sure if I could interprete this as a hardware access denied error (like an I/O error) or a very temporary software permission access denied, like an admin disk write lock or something (again, I'm making best guesses from my limited knowledge).



Yes, it SEEMS to occur only on the same disk. I'm a bit in doubt, because some RD-Read and ER-Erase surface tests using HDDScan return without errors. There have been no errors on the other disks to my knowledge of testing them.

That error that I mentioned, only happened in what I believe to be the last 5% (based on previous times on how long such tests take), which was definitely not the first 3%. Is there a chance that HDDScan Erases memory backwards? That would explain it, otherwise I'm stumbled if its an internal software problem still.


Conclusively, I find it intriguing how little hard evidence is detected on errors. A good question would be, which are good RAID monitoring tools to be 100% sure, that I will receive all or as much information possible, immediately the moment a read/error write occurs? How do corporate organizations monitor successfully their RAID devices with highly important data, and prevent a loss of data on time? I see smartmontools is one small opensource tool, which I'm about to try out, but surely there must be more reliable monitoring tools out there, providing lots more details, and providing lots more accurate and in-depth surface testing ?

Versions prior 3.3 were limited to 1TB capacity

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

@Doomer:

Thanks for that info on the error code I should have guessed that this was a standard Windows error code, and not something that was a specific application error from HDDScan.

@uncleflo:


I suggest that you try the latest v3.3. IIRC there was a fix in that version for some >1TB issues. http://hddscan.com/

[Edit: I see that Doomer kindly confirmed this, while I was typing my reply.]


That last part is the most important. You cannot rely on always getting an error from a faulty disk, so sometimes you might see tests run without errors, even on a faulty disk. It is a useful result, however, if you test all the disks equally (many times each) and only see problems when testing the same one, and never see problems with testing the other disks (even if sometimes, the tests of that "suspect" disk do not report a problem).

To eliminate other parts of the system (SATA cables, ports etc.) you would then just swap 2 of the disks (the "suspect" disk and one other disk) and repeat the testing - do the problems move with the "suspect" disk, or stay with the port (i.e. now start to be reported on the other disk which was swapped)?


I was just trying to get some clarity about whether the location of problems was consistent on your "suspect" disk. As far as I understand you, there is some consistency. Therefore that does tend to point to the disk as the source of the problem (problems external to the disk would not know where on the disk you were testing, and hence should not trigger problems when testing the same part of the disk).


This is why I've pointed you to the Windows System Event Log - that is where Windows logs OS errors. You need to be looking there after an error. Error logging is much more detailed on *nix operating systems.


This is not a Windows support forum, but FYI Windows does log some information in the event log that I mentioned above, when a read/write error occurs. IIRC there are some monitoring tools (management console?) and there are 3rd-party utilities which can then email an administrator (or other actions) when such errors are logged. However the error messages themselves are not easy to interpret IMHO, and (unlike *nix) you can't look at (most of) the Windows source code to get further insight into the errors, beyond what MS choose to document.


For serious RAID use, corporates rarely use Windows software RAID and instead use RAID HBAs or external RAID arrays - all of which come with their own monitoring & adminstration software.


Your answers depend on what you are trying to do, whether you decide to remain limited to Windows software RAID, how much you are willing to spend etc. etc. - but that's all off-topic for data recovery on the forum here. Windows storage architecture and admin topics keep other forums very busy

In the mean time I have changed my faulty disk with two other, similar models. This _could_ allow me to install a RAID6 setup, rather than a RAID5 setup and have extra safety. However, windows 2008 doesn't support Raid6 out of the box, suggestions/drivers are very welcome here.
My current setup is a RAID5 of 4x 2TB disks [or TiB, I'm not sure if which means a factor of 2^10 or 10^3], and a fifth dummy disk that can jump in any moment one of the RAID5 disks fails. RAID6 would be still better, of course.

I tried the GSmartControl tool. Interestingly, it says above each disk a different pd0, pd1, pd2, pd3 etc...
http://gsmartcontrol.berlios.de/home/index.php/en/Home
Now I took an assumption, and guessed that the pd0 numbers were the same as the disk numbers that you see in the standard Windows 2008 disk management interface. The tool, disappointingly, doesn't show which disks are configured within a Raid configuration.

So I tried an experiment, I selected in GSmartControl the disk with the same pd* number as the dummy disk in Win2008 Disk Management, I got the serial number through that, and I plugged the physical serial cable out of that disk with that serial number. In Disk Management, to my great happiness, registered the dummy disk as disconnected.

Now, I am not sure if this was pure luck, or if the pd* numbers are the same as the Disk* numbers between Disk Management and GSmartControl. The big question I _REALLY_ would like to know:

ARE THEY THE SAME??

This would give me at least one way of identifying the physical disk from Software messages, and prepare me in the future to respond immediately without individual disk testing to identify the potential faulty disk.

Eager to know your experiences...