A *both* my harddrives buggered?

[streetster]

Hi Guys,

I bought 2x200gb baraccuda 7200.10's from scan about a month ago. RAID0'd them and installed XP. On tuesday I installed Vista on my spare drive... everything was working fine, then XP decided to die on me.

I had an idea that *one* of the drives was a bit suspect as i couldn't run a full HDtach test on the drive.. but I assumed that once I'd got vista up and running I would be able to transfer my stuff across and then RMA one of the seagates.

Anyhow, it got to the stage yesterday where I windows (vista) would not boot with the RAID array enabled... but I managed to get off the crap i needed by using Active@ Undelete, and creating a 'virtual' drive, so no data lost

Anyhow, I tried running the seagate seatools diagnostic thing last night: the web version told me that it couldnt run because SMART wasnt enabled, so I went for the boot-cd based one. That brought up errors in both the short and long test, for both drives.

So then I decided to do a quick 'chkdsk /r /x /v /f' on the drives. One stopped at 93% (ie it was still on 93% 4 hours later), and the other stopped at 92%. *then* i decided to do a full windows format of both drives.

This morning I tried chkdsk again, to the same result - the first is stuck on 93% the other on 92%.

Are they both buggered? Surely thats pretty unlucky - especially in ~the same place (92/93% through).


Shall I run a low-level format of both the drives and try again? or are there still likely to be defects? basically I dont want to RMA them both back and it turns out they're ok and i get charged!


chkdsk:

[kalniel]

Why are you running /f as well as /x?

I'd personally run just /r /f for the drives, rebooting as required. Sometimes it also takes a few runs.

[streetster]

lol, didnt notice /x implies /f, but still... it stopped at 93/92 before i formatted them fully, and again 93/92 after I did.


right.. just checked chkdsk and it started to move from 93% (the other is still on 92% tho).. first set of results:

C:\>chkdsk f: /f /v /r /x
The type of the file system is NTFS.
Volume label is DRIVE1.

CHKDSK is verifying files (stage 1 of 5)...
  64 file records processed.
File verification completed.
  0 large file records processed.
  0 bad file records processed.
  0 EA records processed.
  0 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 5)...
  164 index entries processed.
Index verification completed.
  5 unindexed files processed.
CHKDSK is verifying security descriptors (stage 3 of 5)...
  64 security descriptors processed.
Cleaning up 1 unused index entries from index $SII of file 9.
Cleaning up 1 unused index entries from index $SDH of file 9.
Cleaning up 1 unused security descriptors.
Fixing mirror copy of the security descriptors data stream.
Security descriptor verification completed.
  10 data files processed.
CHKDSK is verifying file data (stage 4 of 5)...
  48 files processed.
File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
  48816850 free clusters processed.
Free space verification is complete.
Adding 2228 bad clusters to the Bad Clusters File.
Correcting errors in the master file table's (MFT) BITMAP attribute.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

 195360983 KB total disk space.
     21588 KB in 6 files.
        12 KB in 12 indexes.
      8912 KB in bad sectors.
     71983 KB in use by the system.
     65536 KB occupied by the log file.
 195258488 KB available on disk.

      4096 bytes in each allocation unit.
  48840245 total allocation units on disk.
  48814622 allocation units available on disk.

8912 KB in bad sectors. - is that grounds for a RMA?

[Nigelz]

Adding 2228 bad clusters to the Bad Clusters File.

Sounds like the drive is indeed broken, you shouldn't get anything like that normally. Strange that you are having a problem with both drives though, what's the ambient temp of your case, HDD drives are known to fail if they get too hot.

[chrestomanci]

If you set those two drives up as a RAID 0 stripe set, then the filesystem would be striped between the two. If either fails then the filesystem will be lost, and chkdsk will get errors.

Or am I missing something?

[kalniel]

If you set those two drives up as a RAID 0 stripe set, then the filesystem would be striped between the two. If either fails then the filesystem will be lost, and chkdsk will get errors.

Or am I missing something?

File allocation errors, yes, but not bad cluster reports on the free space check surely?

Though it's a good call given they're stopping at the same point. Worth testing outside of RAID to verify.

[this_is_gav]

I'd un-RAID them before doing any tests, but it does sound like both are going.

Welcome to the world of 7200.10s, at least in my experience.

Just out of interest, what is the PSU (it's not listed under 'my system') - probably the only other thing that could break the hard drives themselves - other than a really poor external delivery.

[chrestomanci]

File allocation errors, yes, but not bad cluster reports on the free space check surely?

Though it's a good call given they're stopping at the same point. Worth testing outside of RAID to verify.

The whole file system is under RAID. It is done at the block device level, not the file level.

What RAID does, is take two block devices (in this case of 200,000,000,000 bytes) and interleave the sectors to create a bigger block device of 400 billon bytes. It is onto that block device that Streester created an NTFS filesystem and installed windows.

Every time windows accesses anything on that NTFS file system, including the free space, it is going via RAID, and if one of the drives is faulty, the read will return inconsistent data or fail.

[kalniel]

The whole file system is under RAID. It is done at the block device level, not the file level.

What RAID does, is take two block devices (in this case of 200,000,000,000 bytes) and interleave the sectors to create a bigger block device of 400 billon bytes. It is onto that block device that Streester created an NTFS filesystem and installed windows.

That's bloody clever So RAID is kind of inherently fragmented, but it's happily managed by the controller. I was wondering about defragmentation performance on RAID 0 disks earlier today - the software only sees it as one partition, so tries to create as many contiguous blocks as possible.. only the raid controllers splitting the data off anyway. So is RAID 0 any less/more susceptible to fragmentation?

[streetster]

Guys... the only way I could load windows was to disable the RAID - ie leaving 2 half-baked drives... I then managed to salvage the stuff off the drive using Active@ undelete and creating a virtual drive which 'merged' the two (ie re-raid0'd them in software).

Each drive was then formatted individually (under computer management->storage management), and then chkdsk was run on each drive... The RAID controller played no part in this.

Running Seatools reports errors accross both drives as per this thread in the scan section of the website.

It does seem strange that both drives have failed - especially in the similar area (93/92%)... Maybe a faulty batch?

That's bloody clever So RAID is kind of inherently fragmented, but it's happily managed by the controller. I was wondering about defragmentation performance on RAID 0 disks earlier today - the software only sees it as one partition, so tries to create as many contiguous blocks as possible.. only the raid controllers splitting the data off anyway. So is RAID 0 any less/more susceptible to fragmentation?

The software only sees one partition and tries to create contiguous blocks - but the raid controller interleaves these blocks over the 2 disks (in either 64k / 128k / other chunks)

[chrestomanci]

That's bloody clever So RAID is kind of inherently fragmented, but it's happily managed by the controller. I was wondering about defragmentation performance on RAID 0 disks earlier today - the software only sees it as one partition, so tries to create as many contiguous blocks as possible.. only the raid controllers splitting the data off anyway. So is RAID 0 any less/more susceptible to fragmentation?

The NTFS file system sees a single 400Gb drive. That drive is equally suceptable to fragmentation as a normal drive.

The speed of doing a defrag would probably be a bit slower because RAID volumes have higher latency, because both discs have to seek to the same point, and one will always be slower.