• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About qubit

  • Rank
  1. Indeed. I was hoping you had at least one old hard drive that you weren't using anymore (because it was too small or slow by modern standards). In that case, it would be less of a risk... and in case it was infected with a virus; you could just wipe its MBR. That's what I thought It's annoying that there's no official name for it. I say it should be called "Check Disk", because that's what shows up in the title of the dialog box that pops up. But there isn't any process that shows up in Task Manager; it seems Explorer.exe does the disk checking itself. Probably uses an API call, maybe the same one chkdsk.exe uses (I'm wildly speculating here).
  2. I would very much appreciate it if you would examine the sticker on the underside of the drive's IDE connector, and tell me the 4- or 5-character code (it should be something like "D3FAA"). Please also tell me the manufacture date, which is printed near the bottom-right corner on the top of the drive ("Mfg.Date"), and the size of the drive in GB. I am trying to see if there is a pattern of correlation between PCB versions and manufacture dates. This may give me a clue as to whether I have any chance of finding/buying a drive whose PCB, when swapped, will allow me to recover the data from my own original Maxline II.
  3. An IDE drive will "hide" (relocate) a bad sector under the following conditions: It is told to read a sector, and detects corruption in the sector, but can repair it with ECC. It is told to read a sector, detects unrepairable corruption in a sector, and is later told to overwrite that sector. However, in this case the OS would have detected it as well, and may have marked it as bad on the filesystem level... in which case it would not try to overwrite it. Once a sector is relocated, it pretends to be the same sector as before, except that it's physically located on a different part of the drive. The drive is only capable of doing this for a limited number of sectors, because it has a limited number of spare sectors set aside for this purpose. If it runs out of spares, then all remaining and future bad sectors become permanent. SCSI drives do the same, except they can actually report a list of relocated sectors (but only if asked to do so; software is needed to do this and display the results). On the other hand, bad sectors that are reported by 'chkdsk' were marked by Windows, in the filesystem's Master File Table; in NTFS, there is a "file" called "$Bad" which points out sectors found to be bad. Windows then avoids writing to them at all. If you clone/ghost the partition to a healthy drive, these sectors will still be marked as "bad" even though they are not bad. (In the past I've dealt with this by zeroing-out the 4th file record, belonging to $Bad, with a disk editor; 'chkdsk /r' will then recreate it. But I don't recommend this unless you really know what you're doing.) The reason a zero fill is useful has nothing to do with the fact that it's filling the drive with zeroes; it could also fill the data with random bytes (except for sector 0, the partition table). Writing data to every sector on the drive forces the drive to relocate any latent or pending bad sectors, as long as they were previously detected or are detected during the writing process. Then when you format the drive (i.e., create partition(s)) there will be no bad sectors. There was another thing I was wondering about... Jed2, how did you run 'scandisk' on your NTFS partition? AFAIK, this utility was never included in Windows NT/2000/XP. You can do 'chkdsk' from a command line, and you can also right-click a drive letter in Explorer, click "Properties", then "Tools", then "Check Disk". This second method should behave exactly as chkdsk. Anyway, I wish you luck in figuring out what's wrong! It sure sounds like a doozy, and part of me wishes I could be there debugging it myself... I love a challenge. So, have fun.
  4. Yikes. I must admit to having skimmed the text. I sincerely apologize.I still hold that it's unlikely the hard drive itself is responsible. I would suggest experimenting with plugging in various different hard drives in both master and slave, perhaps old hard drives you weren't using anymore. And what roccovw4 says seems likely to me as well, especially if the "spare comp" has the same kind of motherboard as the comp currently having the problem.
  5. Sounds to me like it is not a hard-drive related problem at all. Sounds like your CMOS battery is depleted, and you should replace it with a fresh one.
  6. I have a feeling that the answer to this question is not a simple one (i.e., something like "the bottom one is 0, and from there it goes 2,4,6,1,3,5,7", or whatever)... otherwise your data recovery guy would have already figured it out.Perhaps the DiamondMax11 is using a new technology, which would confuse someone excepting to see a straightforward numbering of heads. Maybe it uses perpendicular recording, meaning each head would have access to more than one "surface". Though it'd be weird if Maxtor did that without putting it in their specs or press releases. Or... it could be that the DiamondMax11 is the first drive in the line to depart from the simple hierarchy of sectors, tracks, and surfaces. Maybe the drive reads from several tracks in a row before switching to the next head; that could speed things up. I was under the impression that drives started doing that at an earlier generation, but maybe not? I were him (your data recovery guy) I'd have just tried some arbitrary head orderings to see if they worked. There are only two obvious possibilities; if neither of those worked, I would've tried some interleaved orders. I suspect that he did in fact already try these things, and they didn't work; and that even if he were given the correct head ordering, there'd be something extra he'd need to know to actually use the ordering properly. May I ask what kind of data recovery he needs to do on the DiamondMax11 in question? Does it spin up properly, in which case he could use the drive's own heads to recover its data? Or, does he need to scan the data directly from the platters using dedicated hardware?
  7. qubit

    Software RAID 1 on 2x200GB partitions

    In theory, a sophisticated RAID 1 controller or driver could easily speed up concurrent reads from different parts of the volume. As long as the reads were from totally different parts of the drive, it could route some of them to one drive and the rest to the other, simultaneously. However the ability to do this for a single sequential read would be severely hampered by the RAID's lack of knowledge of the hard drives' true physical layout — the best way to optimize sequential reading in a mirrored volume would be to read from even heads on one drive while simultaneously reading from odd heads on the other. This would require only a modest readahead — the length of a single track. There would be no speedup if it tried to interleave reads at a chunk size smaller than the length of a track, because reading within one track is limited by the drive's rotation speed (I guess even that is not set in stone... theoretically I think the phase of rotation could be synchronized to be staggered between two drives; but normal drives are not designed to do that, and there would be no point in it anyway; it'd only cut the necessary readahead in half). So without having precise knowledge of the physical layout of both drives, a RAID would have to do much more readahead and would require more sophisticated programming to be efficient at speeding up sequential reads, and getting practical speedups could be hit-and-miss. (Note that I merely reasoned this out myself; I have no idea to what extent any real RAID 1 implementations optimize reads.)
  8. I still don't understand how you could have all the information necessary except head numbering... how could this possibly be an urgently needed for data recovery? I could understand if you needed lots of information including this. But how could this be such a key item? Aren't there much more complex elements needed, such as the scrambling pattern, coding scheme, ECC algorithm, zone layout, embedded servo format/layout, location/format of factory defect & relocation tables, etc? And if you knew all that and only needed the head numbering, wouldn't it be easy just to reverse engineer that final piece of the puzzle?
  9. I wish you luck in getting your question answered. I've wanted deep technical info on a drive before (the Deathstar 75GXP) and had no luck getting it... in the end I had to reverse engineer it myself. I'm puzzled as to why you (or your data recovery guys) need to be given info on head ordering. If they're transplanting platters, they could simply transplant them into matching positions, without regard to their electronic ordering. If they have the means to read data directly from the platters (for which they'd need much deeper info than head ordering), they could simply find which one has a master boot record on it and start the numbering from there. I can't think of any situation where data recovery people would have all the information they needed except for needing to be told the head numbering. Could you please illuminate me?
  10. qubit


    One thing is pretty certain — you should not use the drive to store any more data. But what you didn't tell us is this: Did you have any important data on the drive that you did not have backed up? Do you want to recover that data? If so, read on.Download and install 010 Editor*. Then start it up, and go File→Open Drive. Double click on the drive letter of your external Maxtor. Make a note of what happened, and then close 010 Editor. If it came up with a page full of various numbers, you're in luck! That would mean you can clone (ghost) the drive. If you want I'll describe how to do the cloning... but first tell me the result of this test. *Note that I did not suggest WinHex (which I personally use) for the initial probing, because if you open a Logical Drive it automatically scans it for a full directory listing. I'm not sure how gracefully it deals with bad sectors when doing that. You could just open the Physical Media corresponding to the drive in question, but I can't tell you precisely which one to choose... you'd maybe have to guess. I wanted to keep my instructions simple.
  11. Oh! I guess I thought of it is "#0" without really realizing it I did try the original again, and it behaved the same as before. It's like it's not even receiving power. (I'd do some simple tests with my multimeter, but it has a fuse I need to replace and I keep forgetting to do so.) You've got a point. The fact that the detection attempt has some effect could mean that a different ATA controller may report what's going on instead of simply coming up empty. But I'm very pessimistic about the chances of actually recovering data that way... I can't think of any reason it could work.Do you think it'd be safe to scan both sides of a PCB in a flatbed scanner? I'd like to scan two and compare them. I'm pretty sure it'd be safe if I put the PCB inside a hard drive bag, but that would tint and degrade the scan.
  12. PCB #2 is the one that managed to spin up the drive... I strongly suspect that PCB #1 would still just make a soft high-pitched whine like it did before. Of course the scientific thing to do would be to try #1 again just to see if it does do as before... and I could record + post the sound. Exactly... I was only able to recover data from my Deathstar because it was still detected and accessable.Thanks for wishing me luck before My recovery effort panned out beautifully. I was able to reverse engineer the drive's RLL and ECC schemes, and combining this with filling in data from context was enough to recover a good amount of data. I still haven't recovered all the bad sectors that are recoverable and important to me... so I've kept the ghosted partition online, un-resized and un-defragmented to allow me continue the project when I want. It's the only FAT partition I still actively use (not counting flash cards)... it's not a carbon copy of the bad drive anymore, but unchanged files still occupy the same clusters. I find it very unfortunate that when the ATA spec was extended to use 48 addressing bits, READ LONG and WRITE LONG were not included. There are no 48-bit versions of those commands. So I wouldn't be able do the same thing with a >128GiB drive, sadly.
  13. qubit


    Through what interface is it plugged in (USB, Firewire, etc)? Does its drive letter show up? At what point does "I/O Error" show up?
  14. Or maybe it's looking for the firmware / mapping tables in the right place, but trying to parse them in the wrong format... who knows what kinds of things Maxtor may have changed between PCB revisions. :-\ About the detection thing... I also have a seven year old IBM Ultrastar DMVS-36D that no longer spins up (it tries but fails). Interestingly, it is still detected, but as "DMVS" instead of "DMVS-36D" (and of course the sectors are inaccessable). I wonder why the Maxtor doesn't do something similar.
  15. Oof, I forgot to say that it's not detected. At all. The only sign that it's plugged into the IDE cable is that when the BIOS or OS try to detect it, it makes that sound.From what I know of hard drives, that could mean that there's a "bad sector" on a critical area of the drive, like in the firmware or sector mapping tables stored magnetically in the drive, right? But it could also mean that the swapped PCB still doesn't match the drive's setup in some way... maybe it's trying to load that information from the wrong physical sectors (and by physical I mean truly physical, not LBA).