(This is not a BIOS or Windows issue) Drive size problem.

[umop]

I have two identical Western Digital 250GB hard disks which were
previously in a RAID array in a Lacie D2 BigDisk enclosure. When I
place either inside any other controller I have, I end up with one
showing up at it's accurate 250GB value, and the other at a truncated
128GB. I have gone into WinHex, a disk editor, and found the following
information being reported:

Disk 1 (Wrong):

cyls 16709
heads 255
sectors per track 63
bytes sect 512
surplus sectors 3323
reported size: 137437904896 bytes

Disk 2 (Correct):

cyls 30401
heads 255
sectors per track 63
bytes sect 512
surplus sectors 3711
reported size: 250058637312 bytes

It appears that the physical parameters on this disk are incorrect, and
I need to find out where they are stored so I can change them and
restore the data from my disk. I have tried swapping the driver cards
from the good HD (disk 2) to the bad one (disk 1), and it still shows
the same values. I don't care about continuing to use the disk, I just
need to be able to read everything so i can get my data back.

Any ideas what program I can use to change the disk parameters of the
incorrect disk, or at least a method I can use to retrieve the (raw)
data?

Thanks,
Eric

 

[okcmike]

Use WD's Data Lifeguard Tool's 'Set Hard Drive Size' utility to correct
the hard drives capacity.

 

[Folkert Rienstra]

I have two identical Western Digital 250GB hard disks which were
previously in a RAID array in a Lacie D2 BigDisk enclosure.

So either 'RAID0' or 'Spanned'.

When I place either inside any other controller I have, I end up with one
showing up at it's accurate 250GB value, and the other at a truncated
128GB. I have gone into WinHex, a disk editor, and found the following
information being reported:

Disk 1 (Wrong):

cyls 16709
heads 255
sectors per track 63
bytes sect 512
surplus sectors 3323
reported size: 137437904896 bytes

Disk 2 (Correct):

cyls 30401
heads 255
sectors per track 63
bytes sect 512
surplus sectors 3711
reported size: 250058637312 bytes

It appears that the physical parameters on this disk are incorrect,

Not from that report above. Those are not the physical parameters.
Those are logical parameters, and as such they are even false as CHS
is not supported above 8GB. The surplus sectors may indicate that
they aren't even for the whole drive but for a partition instead.
They are LBA values converted to a CHS notation just for display
purposes though God knows what that purpose may be.
CHS was useful in determining whether partiton boundaries were
on full cylinders when harddrives were below 8GB capacity.
It's usefulness has long passed it's use by date since.

and I need to find out where they are stored so I can change them and
restore the data from my disk.

What 'disk'.

I have tried swapping the driver cards from the good HD (disk 2)
to the bad one (disk 1), and it still shows the same values.

Likely because that data is kept on the platters, whether it is MBR or
the physical disk's configuration sector that's causing your problems.

I don't care about continuing to use the disk, I just need
to be able to read everything so i can get my data back.

Maybe things get clearer once you state your problem.

 

[Eric Gisin]

So either 'RAID0' or 'Spanned'.



Not from that report above. Those are not the physical parameters.
Those are logical parameters, and as such they are even false as CHS
is not supported above 8GB. The surplus sectors may indicate that
they aren't even for the whole drive but for a partition instead.
They are LBA values converted to a CHS notation just for display
purposes though God knows what that purpose may be.
CHS was useful in determining whether partiton boundaries were
on full cylinders when harddrives were below 8GB capacity.
It's usefulness has long passed it's use by date since.

Still confused by the CHS values Win NT reports, FolkNuts?
You get the same values from findpart, dskprobe, and winhex.
Yes, Win NT still aligns basic disk partitions on cylinder boundries.
Not surprising since it was documented by MS 10 years ago.

 

[Folkert Rienstra]

Still confused by the CHS values Win NT reports, FolkNuts?

Nope, but it's obvious that you are.
Now we know why you are known as "the Gisin newby".
The only one confused is you, Gisin.

Go read the ATA spec and the EDD BIOS spec, newby.
Or the Enhanced Bios Services For Disk Drives spec.
Or the MBR partition table spec.
They all say that CHS is restricted to 8GB in one way or another.

You know full well that I am correct.
And if not then you are indeed a truly pathetic newby.

Where were you when Antoine Leca confirmed what I said then
and what I say now. You know you wouldn't have stood a chance
then, don't you, Gisin. Which makes you kind of a RAT.

You get the same values from findpart, dskprobe, and winhex.

Ah, and that makes it right. It also does that for SCSI drives
and every one and his dog knows that SCSI doesn't use CHS at all.
But then a newby like yourself may not know that, don't you, newby.
What a bullshit artist you are, Gisin.

And it is that terminal stupid mentality of insisting of using bogus CHS
internally that makes some windowses based on NT not recognize the full
capacity of some harddrives but limit them to 8GB or 32 GB instead if the
bios parameters are not to their liking or the stars are in the wrong place.

Yes, Win NT still aligns basic disk partitions on cylinder boundries.

That's silly, especially for those partition types that don't use CHS
at all, the LBA-only partition types.

Not surprising since it was documented by MS 10 years ago.

But isn't used for partitions currently and partitions aren't exactly
a MS invention. The only requirement for CHS currently is in booting
a harddrive with an ancient bootstrap loader using legacy Int13.

 

[umop]

Those are not the physical parameters

In WinHex, you are given the option to open "Logical Drives", or
"Physical Media." I am accessing the physical disk under the "Physical
Media" section, not a partition or logical disk, so I don't believe
that to be true. Additionally, from this view, I can see several
partitions, one being the NTFS partition that I'm interested in.

Whether the CHS values are extrapolated from the LBA values or not, the
size is still being misreported either way, and I cannot access about
half of my data from this 250GB drive. I agree, since the swapping of
driver cards yielded the same result, that it appears that the
incorrect information must somehow be stored on the platters, but I'm
unclear as to how get any deeper than I already am (the physical disk)
to alter those parameters and dump an image of this drive. The
previous poster suggested to use Western Digital's Lifeguard tools to
set the size of the disk, but I want to exhaust all other possibilities
before I trust my data to that tool.

You mentioned the physical disk's configuration sector. Is there a way
to access and modify that? I have looked up information on the MBR
before, and it appeared to only contain info on partitions. Not the
actual physical disk.

Thanks much for the help!

 

[Folkert Rienstra]

Read my lips:

 

[umop]

Okay. If that's true, how should I access the physical disk instead of
a logical one, if indeed the result of opening the "Physical Media" in
my disk editor yields a logical disk? I'm not clear why this would be
the case, but I'm open to suggestions. Which disk editor would be best
for this? Is there a particular controller I should try (I'm on a
notebook, unfortunately, so I can't plug into a hardware EIDE cable).

Thanks,
Eric

 

[umop]

So, as you can see, that other thread wasn't very helpful for me. Can
you offer any suggestions for me, Eric?

Thanks
Eric

 

[Folkert Rienstra]

So, as you can see, that other thread wasn't very helpful for me.

It wasn't helpful because you weren't very helpful yourself.
That's what you get for snipping, ignoring requests for info
and being selfcentered, calling Western Digital's Lifeguard
tools untrustworthy. You got treated the same way back.

My post is still there, so why don't you try again.

Can you offer any suggestions for me, Eric?

You must be quite desperate to ask the Gisin Newbie,
(but not desperate enough to use WD's tools?).

 

[Odie]

It wasn't helpful because you weren't very helpful yourself.
That's what you get for snipping, ignoring requests for info
and being selfcentered,

Selfcentred.

Folkert, you epitomise the art of being "selfcentred" [sic].

Let's hope the rest of the week improves for you!


Odie

 

[Svend Olaf Mikkelsen]

Use WD's Data Lifeguard Tool's 'Set Hard Drive Size' utility to correct
the hard drives capacity.

If the disk is not set to 128 GB using jumpers. In that case, correct
the jumper setting.

 

[Folkert Rienstra]

Hi Svend, had a long good sabbatical?

If the disk is not set to 128 GB using jumpers.
In that case, correct the jumper setting.

Well, that should be an accidental jumper setting then since you don't
just forget that you set it, not with that kind of problem description.

 

[umop]

If the disk is not set to 128 GB using jumpers. In that case, correct

the jumper setting.

I saw the size limiting jumper option in the documentation, but it is
not set to limit. Also, I have actually swapped the driver card
containing the jumpers between the two drives and still had the same
result. Good thought though.

 

[Folkert Rienstra]

I saw the size limiting jumper option in the documentation, but it is
not set to limit. Also, I have actually swapped the driver card
containing the jumpers between the two drives and still had the same
result. Good thought though.

Still stubbornly refusing to provide more info.

 

[umop]

I thought I had responded to all requests for info. My apologies if
this is not the case. The reason I said the thread wasn't very helpful
for me is that it ended with me trying to clarify your comment:

Those are not the physical parameters

with no response for a week (see below for reference), so I sought more
advice:

Okay. If that's true, how should I access the physical disk instead of

a logical one, if indeed the result of opening the "Physical Media" in
my disk editor yields a logical disk? I'm not clear why this would be
the case, but I'm open to suggestions. Which disk editor would be best

for this? Is there a particular controller I should try (I'm on a
notebook, unfortunately, so I can't plug into a hardware EIDE cable).

Additionally, I'm not calling WD tools untrustworthy. I just don't
want to perform an action which will potentially irreversibly write to
the drive until I clear up questions such as your statement above.

On being self centered and seeking advice from Eric Gisin, I'm open to
suggestions from you and everyone here. I don't think that a tech
forum is a place for personal attacks or flames, and I appreciate all
help given.

 

[umop]

I'm not following. What more info should I provide? I'll gladly do so.

 

[Folkert Rienstra]

last chance:

I have two identical Western Digital 250GB hard disks which were
previously in a RAID array in a Lacie D2 BigDisk enclosure.

So either 'RAID0' or 'Spanned'.

When I place either inside any other controller I have, I end up with one
showing up at it's accurate 250GB value, and the other at a truncated
128GB. I have gone into WinHex, a disk editor, and found the following
information being reported:

Disk 1 (Wrong):

cyls 16709
heads 255
sectors per track 63
bytes sect 512
surplus sectors 3323
reported size: 137437904896 bytes

Disk 2 (Correct):

cyls 30401
heads 255
sectors per track 63
bytes sect 512
surplus sectors 3711
reported size: 250058637312 bytes

It appears that the physical parameters on this disk are incorrect,

Not from that report above. Those are not the physical parameters.
Those are logical parameters, and as such they are even false as CHS
is not supported above 8GB. The surplus sectors may indicate that
they aren't even for the whole drive but for a partition instead.
They are LBA values converted to a CHS notation just for display
purposes though God knows what that purpose may be.
CHS was useful in determining whether partiton boundaries were
on full cylinders when harddrives were below 8GB capacity.
It's usefulness has long passed it's use by date since.

and I need to find out where they are stored so I can change them and
restore the data from my disk.

What 'disk'.

I have tried swapping the driver cards from the good HD (disk 2)
to the bad one (disk 1), and it still shows the same values.

Likely because that data is kept on the platters, whether it is MBR or
the physical disk's configuration sector that's causing your problems.

I don't care about continuing to use the disk, I just need
to be able to read everything so i can get my data back.

Maybe things get clearer once you state your problem.

 

[umop]

I'll try to be more detailed. Here is everything I have:

First, this appears to be a non-conventional RAID setup as either
halves of the disk is wholly accessible (aside from the size being
incorrectly reported on disk A), and do not seem to be broken up in to
stripes. Rather, the disk appears that it was broken up into two 250GB
chunks (which is good for recovery). I say this because I've been able
to recover whole files from the space i can see, and they recover
perfectly. The RAID setup should be irrelevant, as I'm presently only
trying to read the raw disks individually at the moment.

When I open up the first disk of the RAID array as a *Physical Volume*,
I can see the following partitions:

Partition 1 (31.5KB, Apple Map)
Partition 2 (64.0KB, Apple Aux)
Partition 3 (64.0KB, Apple Aux)
Partition 4 (112KB, Apple Aux)
Partition 5 (112KB, Apple Aux)
Partition 6 (466GB, ?)
Partition 7 (283KB, Apple Aux)

When I search the drive for lost partitions, I find the additional
partition I'm interested in:

Partition 8 (466GB, NTFS, lost)

This partition starts at offset 0000007E00

When I traverse this, I can see a number of files, and recover them.
The partition is too large to be completely traversed as the disk
should only hold half of the original 466GB partition. Even with that,
though, the first drive peters out at offset 1FFFEFFFFF
(137,437,904,895 bytes), where the second (physically identical) drive
is readable all the way to offset 3A38A7FFFF (250,058,637,311 bytes).
My intention is to take the partition and stitch the two halves
together onto another drive to make a whole image of the original
partition, and then recover my files, but a good chunk of my data
(first drive, Offset 1FFFF00000 through 3A38A7FFFF) is unreadable.

The second drive contains no partitions at all and appears to simply be
a continuation of data from the first drive.

The physical drive parameters as interpreted by WinHex are:

Disk 1: 137,437,904,896 bytes
Disk 2: 250,058,637,312 bytes

I have tried interfacing to the drives via a Maxtor One-touch enclosure
(previously containing a 300GB drive) and a generic brand controller
rated for 400GB drives (but I've tested with a 500GB drive
successfully). I had originally used an older enclosure which I had
not tested with larger drives, and I suspect that this enclosure
somehow caused the drive parameter mismatch. Though, that is only a
suspicion.

Any suggestions are greatly appreciated (OS, Software, controller,
etc).

Many thanks!

 

[umop]

Correction:

I said: "The second drive contains no partitions at all and appears to
simply be a continuation of data from the first drive."
I meant: "The second drive contains no partitions headers at all and
appears to simply be a continuation of the NTFS partition's data which
began on the first drive."