Results 1 to 11 of 11

Thread: A *both* my harddrives buggered?

  1. #1
    cat /dev/null streetster's Avatar
    Join Date
    Jul 2003
    Location
    London
    Posts
    4,138
    Thanks
    119
    Thanked
    100 times in 82 posts
    • streetster's system
      • Motherboard:
      • Asus P7P55D-E
      • CPU:
      • Intel i5 750 2.67 @ 4.0Ghz
      • Memory:
      • 4GB Corsair XMS DDR3
      • Storage:
      • 2x1TB Drives [RAID0]
      • Graphics card(s):
      • 2xSapphire HD 4870 512MB CrossFireX
      • PSU:
      • Corsair HX520W
      • Case:
      • Coolermaster Black Widow
      • Operating System:
      • Windows 7 x64
      • Monitor(s):
      • DELL U2311
      • Internet:
      • Virgin 50Mb

    A *both* my harddrives buggered?

    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:


  2. #2
    Senior Member kalniel's Avatar
    Join Date
    Aug 2005
    Posts
    29,175
    Thanks
    1,515
    Thanked
    2,930 times in 2,374 posts
    • kalniel's system
      • Motherboard:
      • Gigabyte X58A UD3R rev 2
      • CPU:
      • Intel Xeon X5680
      • Memory:
      • 12gb DDR3 2000
      • Graphics card(s):
      • nVidia GTX 1060 6GB
      • PSU:
      • Seasonic 600W
      • Case:
      • Cooler Master HAF 912
      • Operating System:
      • Win 10 Pro x64
      • Monitor(s):
      • Dell U2311H
      • Internet:
      • O2 8mbps
    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.

  3. #3
    cat /dev/null streetster's Avatar
    Join Date
    Jul 2003
    Location
    London
    Posts
    4,138
    Thanks
    119
    Thanked
    100 times in 82 posts
    • streetster's system
      • Motherboard:
      • Asus P7P55D-E
      • CPU:
      • Intel i5 750 2.67 @ 4.0Ghz
      • Memory:
      • 4GB Corsair XMS DDR3
      • Storage:
      • 2x1TB Drives [RAID0]
      • Graphics card(s):
      • 2xSapphire HD 4870 512MB CrossFireX
      • PSU:
      • Corsair HX520W
      • Case:
      • Coolermaster Black Widow
      • Operating System:
      • Windows 7 x64
      • Monitor(s):
      • DELL U2311
      • Internet:
      • Virgin 50Mb
    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:

    Code:
    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?
    Last edited by streetster; 25-01-2007 at 01:39 PM.

  4. #4
    Member
    Join Date
    Nov 2006
    Posts
    55
    Thanks
    0
    Thanked
    0 times in 0 posts
    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.

  5. #5
    Senior Member chrestomanci's Avatar
    Join Date
    Sep 2004
    Location
    Reading
    Posts
    1,603
    Thanks
    91
    Thanked
    95 times in 79 posts
    • chrestomanci's system
      • Motherboard:
      • Asus AMD AM4 Ryzen PRIME B350M
      • CPU:
      • AMD Ryzen 1600 @ stock clocks
      • Memory:
      • 16Gb DDR4 2666MHz
      • Storage:
      • 250Gb Samsung 960 Evo M.2 + 3Tb Western Digital Red
      • Graphics card(s):
      • Basic AMD GPU (OSS linux drivers)
      • PSU:
      • Novatech 500W
      • Case:
      • Silverstone Sugo SG02
      • Operating System:
      • Linux - Latest Xubuntu
      • Monitor(s):
      • BenQ 24" LCD (Thanks: DDY)
      • Internet:
      • Zen FTTC
    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?

  6. #6
    Senior Member kalniel's Avatar
    Join Date
    Aug 2005
    Posts
    29,175
    Thanks
    1,515
    Thanked
    2,930 times in 2,374 posts
    • kalniel's system
      • Motherboard:
      • Gigabyte X58A UD3R rev 2
      • CPU:
      • Intel Xeon X5680
      • Memory:
      • 12gb DDR3 2000
      • Graphics card(s):
      • nVidia GTX 1060 6GB
      • PSU:
      • Seasonic 600W
      • Case:
      • Cooler Master HAF 912
      • Operating System:
      • Win 10 Pro x64
      • Monitor(s):
      • Dell U2311H
      • Internet:
      • O2 8mbps
    Quote Originally Posted by chrestomanci View Post
    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.

  7. #7
    Senior Member this_is_gav's Avatar
    Join Date
    Dec 2005
    Location
    Alnwick, Northumberland
    Posts
    4,835
    Thanks
    175
    Thanked
    246 times in 213 posts
    • this_is_gav's system
      • Motherboard:
      • DFI DK X58-T3eH6
      • CPU:
      • Intel i7 920
      • Memory:
      • 12GB Corsair 1333MHz C9
      • Storage:
      • 2xRaptor 150GB (RAID0 300GB), 2.5TB permanent storage
      • Graphics card(s):
      • Nvidia GTX 560 Ti 1GB
      • PSU:
      • Seasonic X-series
      • Case:
      • Lian-Li A70B
      • Operating System:
      • Windows 7 x64
      • Monitor(s):
      • Dell 2408WFP
      • Internet:
      • 8M ADSL24
    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.

  8. #8
    Senior Member chrestomanci's Avatar
    Join Date
    Sep 2004
    Location
    Reading
    Posts
    1,603
    Thanks
    91
    Thanked
    95 times in 79 posts
    • chrestomanci's system
      • Motherboard:
      • Asus AMD AM4 Ryzen PRIME B350M
      • CPU:
      • AMD Ryzen 1600 @ stock clocks
      • Memory:
      • 16Gb DDR4 2666MHz
      • Storage:
      • 250Gb Samsung 960 Evo M.2 + 3Tb Western Digital Red
      • Graphics card(s):
      • Basic AMD GPU (OSS linux drivers)
      • PSU:
      • Novatech 500W
      • Case:
      • Silverstone Sugo SG02
      • Operating System:
      • Linux - Latest Xubuntu
      • Monitor(s):
      • BenQ 24" LCD (Thanks: DDY)
      • Internet:
      • Zen FTTC
    Quote Originally Posted by kalniel View Post
    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.

  9. #9
    Senior Member kalniel's Avatar
    Join Date
    Aug 2005
    Posts
    29,175
    Thanks
    1,515
    Thanked
    2,930 times in 2,374 posts
    • kalniel's system
      • Motherboard:
      • Gigabyte X58A UD3R rev 2
      • CPU:
      • Intel Xeon X5680
      • Memory:
      • 12gb DDR3 2000
      • Graphics card(s):
      • nVidia GTX 1060 6GB
      • PSU:
      • Seasonic 600W
      • Case:
      • Cooler Master HAF 912
      • Operating System:
      • Win 10 Pro x64
      • Monitor(s):
      • Dell U2311H
      • Internet:
      • O2 8mbps
    Quote Originally Posted by chrestomanci View Post
    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?

  10. #10
    cat /dev/null streetster's Avatar
    Join Date
    Jul 2003
    Location
    London
    Posts
    4,138
    Thanks
    119
    Thanked
    100 times in 82 posts
    • streetster's system
      • Motherboard:
      • Asus P7P55D-E
      • CPU:
      • Intel i5 750 2.67 @ 4.0Ghz
      • Memory:
      • 4GB Corsair XMS DDR3
      • Storage:
      • 2x1TB Drives [RAID0]
      • Graphics card(s):
      • 2xSapphire HD 4870 512MB CrossFireX
      • PSU:
      • Corsair HX520W
      • Case:
      • Coolermaster Black Widow
      • Operating System:
      • Windows 7 x64
      • Monitor(s):
      • DELL U2311
      • Internet:
      • Virgin 50Mb
    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?

    Quote Originally Posted by kaniel
    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)
    Last edited by streetster; 26-01-2007 at 12:47 AM.

  11. #11
    Senior Member chrestomanci's Avatar
    Join Date
    Sep 2004
    Location
    Reading
    Posts
    1,603
    Thanks
    91
    Thanked
    95 times in 79 posts
    • chrestomanci's system
      • Motherboard:
      • Asus AMD AM4 Ryzen PRIME B350M
      • CPU:
      • AMD Ryzen 1600 @ stock clocks
      • Memory:
      • 16Gb DDR4 2666MHz
      • Storage:
      • 250Gb Samsung 960 Evo M.2 + 3Tb Western Digital Red
      • Graphics card(s):
      • Basic AMD GPU (OSS linux drivers)
      • PSU:
      • Novatech 500W
      • Case:
      • Silverstone Sugo SG02
      • Operating System:
      • Linux - Latest Xubuntu
      • Monitor(s):
      • BenQ 24" LCD (Thanks: DDY)
      • Internet:
      • Zen FTTC
    Quote Originally Posted by kalniel View Post
    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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Need help on my maxtor harddrives
    By arthurleung in forum PC Hardware and Components
    Replies: 10
    Last Post: 12-06-2007, 09:40 PM
  2. What harddrives for RAID 0?
    By streetster in forum PC Hardware and Components
    Replies: 10
    Last Post: 17-11-2006, 12:49 AM
  3. Samsung harddrives, not so quiet
    By eldren in forum PC Hardware and Components
    Replies: 16
    Last Post: 12-12-2004, 08:56 PM
  4. Raptor Harddrives
    By ollyjones in forum Retail Therapy and Bargains
    Replies: 13
    Last Post: 08-11-2004, 11:16 AM
  5. CDROMS and HARDDRIVES
    By bluephi1914 in forum PC Hardware and Components
    Replies: 5
    Last Post: 28-10-2003, 11:44 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •