Help! - Reaching 45gb of data wipes out new 80gb drive???

[Rick]

My Micron Transport GX+ notebook (model is from 2000) has a 30gb IDE
main hard drive (originally 10gb) plus another 30gb drive that I
installed in in the options bay a few years ago. Both hdds were
Hitachi/IBM, and I had no trouble installing or using either one.
(Performance of the secondary hdd has always been pretty sluggish,
although I doubt that this was due to the drive itself).

The secondary drive seemed to be going bad over the last
few months -- often the system wouldn't even recognize it until
several reboots, and I would hear clacking noises at times. Since I
thought this was likely due to the pc "roughing up" the drive in that
bay, I decided to eliminate it, stop using a secondary hdd, and
instead replace the main 30gb hdd with an 80gb Hitachi.

A few years ago Micron (now MPC) support told me the pc could not
handle hdd's greater than 30 (or maybe it was 40gb). But about a year
ago a salesperson at MPC insisted that I had been given incorrect info
driven by the fact that 30 or 40gb was the largest drive size
available when the system was being sold. She told me she
double-checked with tech support and was assured that, contrary to the
earlier advice, the system could
indeed handle much larger drives.

So, using Drive Image 5.0 I created a clone of my 30gb
primary drive onto the new 80gb hdd, again all as one partition
(which means I had Drive Image expand the approx 30gb C partition to
approx 80gb.) Went without a hitch. The BIOS conformed the drive as
80 gb.

Then I started adding data to the new 80 gb hard drive (on top of the
approx 24 gb of data I had transferred over via the Drive Image copy).
But when I got to about 45 gb of data -- ie., added about 21 gb (not
all at once, BTW) -- Windows Explorer said something to the effect of
"drive full, please delete some files". And then -- here's the kicker
-- when I clicked "OK", the system crashed, and upon reboot I was left
with a completely data-less, UNFORMATTED disk. Norton Disk Doctor
rescue disk could recognize no data, and was able to do nothing. I
was left with a start from scratch proposition (fortunately I had the
old disk as a backup).

Several more tries, same result! I even tried dividing the new disk
into three partions < 30 gb each in case there was some sort of
partition size issue, but with the exact same result. I also tried
using Drive Image to copy over the data from the old secondary drive
as a full partition -- rather than simply copying via Windows Explorer
-- but here Drive Image would get about 50-70% through the copy
process, say "Drive Read Error" and stop…and the result would be the
same: new main drive instantly and completely wiped out. Another
thing I tried, updating the BIOS to the latest version (Phoenix 4.0
Rev 6, 11/03), didn't help either.

This all raises two questions:
-- Why am I reaching the capacity issue, and
-- Even more troubling…assuming some pc component or some relevant
software
really DOES have a capacity limitation of 40-50gb, shouldhitting
this maximum capacity instantly nuke all data and formatting????
Could
the new 80gb HDD be bad? If so, how can I tell?

Would greatly appreciate any ideas, suggestions. My own knowledge of
hardware issues is moderate or lower. For now, I've just gone back to
the 30gb main drive (and archived what was on thesecondary to external
storage), because I can't take a chance on losing everything whenever
I reach some apparent limit ofsomewhere between 40-50 gb on the new 80
gb hdd.

BTW, there's no evidence whatsoever of a virus. OS is Win98SE,
Pentium 700.

Thanks in advance,
Rick

 

[Mike Redrobe]

A few years ago Micron (now MPC) support told me the pc could not
handle hdd's greater than 30 (or maybe it was 40gb).
32GB.

Then I started adding data to the new 80 gb hard drive (on top of the
approx 24 gb of data I had transferred over via the Drive Image copy).

But when I got to about 45 gb of data -- ie., added about 21 gb (not
all at once, BTW) -- Windows Explorer said something to the effect of
"drive full, please delete some files". And then -- here's the kicker
-- when I clicked "OK", the system crashed, and upon reboot I was left
with a completely data-less, UNFORMATTED disk.

I doubt the limit is 40-50gb, probably 32GB:

65536 Cyls, 16 Heads and 63 Sectors/Track
with 512 bits per sector;

65536 x 16 x 63 x 512 = 33,822,867,456 -> 31.5 GB

Once you go over 31.5, any extra data will "wrap around" to the
beginning, overwriting sector 0 onwards etc

Since this is at drive geometry level, you can't get around it by
having lots of partitions past the 31GB mark.

i.e a single 31GB partition on a drive is the max, any other
partitions after that would be mapped into the start of the
first - and you won't notice until you put data on, and wipe
stuff out - as you found..

This limit is in some (pre 2000?) BIOS and also Win95

Win98SE should be ok, but microsoft have the following patch:
http://www.microsoft.com/windows98/downloads/contents/WURecommended/S_WUFeatured/bigide/Default.asp

 

[Rick]

I doubt the limit is 40-50gb, probably 32GB

Your explanation for that conclusion was helpful and made a lot of
sense. However, I know for sure that when copying over data, the
crash didn't occur until sometime after I had "successfully" added
entire folders that would have brought me up to *at least* 41gb usage
of the 80. Of course, I can't say whether things would have REMAINED
stable for long, had I stopped copying sooner (yet above 32gb). (Thus
the quotes around "successfully".)

Win98SE should be ok, but microsoft have the following patch:
http://www.microsoft.com/windows98/downloads/contents/WURecommended/S_WUFeatured/bigide/Default.asp

Am I misinterpreting, or is this patch strictly for fixing potential
Scandisk misreads on larger drives? I.e., in and of itself the patch
wouldn't do anything to help make the full capacity of the drive
useable -- right?

Thanks again for the ideas.

 

[Folkert Rienstra]

I doubt the limit is 40-50gb, probably 32GB:

65536 Cyls, 16 Heads and 63 Sectors/Track

Uhh? Who pulled that rabbit out of the hat?

with 512 bits per sector;

65536 x 16 x 63 x 512 = 33,822,867,456 -> 31.5 GB

That is an invalid drive CHS (P-CHS).
Both INT13 CHS (L-CHS) and drive CHS are limited to 8GB.
So although the C=65536 and H=16 are both valid numbers for
a P-CHS by themselfs, the combination is not.

Once you go over 31.5, any extra data will "wrap around" to the
beginning, overwriting sector 0 onwards etc

Since this is at drive geometry level,

Drive geometry stops at 8GB already. Anything above that is LBA.
However something is using Pseudo CHS internally and that is what
has the modulo 32GB bug.

you can't get around it by having lots of partitions past the 31GB mark.

If that is what you mean with "drive geometry level", true. But it
would be the same for the L-CHS, as recorded in the partition tables.

i.e a single 31GB partition on a drive is the max, any other
partitions after that would be mapped into the start of the
first - and you won't notice until you put data on, and wipe
stuff out - as you found..

Actually extended partitions have their EMBR, FATs and DIRs at
their start. Even making them will write into the start of the first.
If (un)lucky, the EMBR is overwriting the MBR, else it is in the
FATs or in the directories or in the data area of the primary partition.
Formatting them will then make it worse.
If the primary still works after that this should go wrong very quickly,
starting with the extendeds disappearing when the primary fills up.

 

[Rick]

(Mike Redrobe

Drive geometry stops at 8GB already. Anything above that is LBA.
However something is using Pseudo CHS internally and that is what
has the modulo 32GB bug.


If that is what you mean with "drive geometry level", true. But it
would be the same for the L-CHS, as recorded in the partition tables.


Actually extended partitions have their EMBR, FATs and DIRs at
their start. Even making them will write into the start of the first.
If (un)lucky, the EMBR is overwriting the MBR, else it is in the
FATs or in the directories or in the data area of the primary partition.
Formatting them will then make it worse.
If the primary still works after that this should go wrong very quickly,
starting with the extendeds disappearing when the primary fills up.

With my limited knowledge, I only partially understand what you're
talking about. It seems that while you differ on the explanation, you
agree with Mike Redrobe that there is a 32gb limitation (even though
the crashes didn't occur until I had copied well beyond 32gb onto the
80gb drive). It took me awhile to figure out what CHS and L-CHS stood
for.

Bottom line, do you have any suggestions on how I might specifically
pinpoint where the "something" is that is causing the 32gb limitation
"bug", as you call it, and remedy the situation? Or is this something
best left to experts? Or do you feel the problem probably just isn't
practically solveable?

Thanks,
Rick

 

[Folkert Rienstra]

(Mike Redrobe

With my limited knowledge, I only partially understand what you're
talking about.

Yeah, it's a real mess. No wonder that there are so many bugs.

It seems that while you differ on the explanation,

you agree with Mike Redrobe that there is a 32gb limitation

Yes, it appears so that there is such a limitation/problem/bug.
Someone goofed-up by probably using pseudo CHS in the drivers or
'somewhere' as only LBA addressing can be used for anything over 8GB.
That somebody probably didn't anticipate that drives would grow
to over 32GB or he just used the individual P-CHS limits but ignored
the rules for them. That will give you a somewhat natural 32GB limit.
But even then, it is still bad programming (a bug as opposed to a limita-
tion) as any decent software shall check for counter/register overflow.

(even though the crashes didn't occur until I had copied well
beyond 32gb onto the 80gb drive).

That is possible if you have to hit a certain spot on your primary partition
to tackle the running system. That spot may be a program file that you are
calling at the point of crash or maybe your swapfile when some swapped-out
program swaps back in.

If you had rebooted (before any crash) you may have run into trouble much
earlier when you would have noticed that your bootrecord and other vital
data for booting would have been wiped out already too.

It took me awhile to figure out what CHS and L-CHS stood for.

A software or Logical geometry detail that was derived from the Physical
geometry detail long ago and abandoned after drives got bigger than 8GB.
Now L-CHS and P-CHS are both logical (not really existing physically,
nevermind that P-) geometries.
Drives use a 16386 cylinder/16 head maximum and BIOS INT13 uses a
1024 cylinder/256 head maximum to expand on an earlier 1024 16 63 limit.
L is for the program interface side of the BIOS, P is for the drive side
(the IDE physical interface) of the BIOS.

Bottom line, do you have any suggestions on how I might specifically
pinpoint where the "something" is that is causing the 32gb limitation
"bug", as you call it, and remedy the situation?

Svend Olaf Mikkelsen has a program GB32 that can pinpoint it for you.
http://www.partitionsupport.com/utilities.htm

If you have the problem then the link to M$ should get you sorted.

 

[Rick]

Yeah, it's a real mess. No wonder that there are so many bugs.



Yes, it appears so that there is such a limitation/problem/bug.
Someone goofed-up by probably using pseudo CHS in the drivers or
'somewhere' as only LBA addressing can be used for anything over 8GB.
That somebody probably didn't anticipate that drives would grow
to over 32GB or he just used the individual P-CHS limits but ignored
the rules for them. That will give you a somewhat natural 32GB limit.
But even then, it is still bad programming (a bug as opposed to a limita-
tion) as any decent software shall check for counter/register overflow.


That is possible if you have to hit a certain spot on your primary partition
to tackle the running system. That spot may be a program file that you are
calling at the point of crash or maybe your swapfile when some swapped-out
program swaps back in.

If you had rebooted (before any crash) you may have run into trouble much
earlier when you would have noticed that your bootrecord and other vital
data for booting would have been wiped out already too.


A software or Logical geometry detail that was derived from the Physical
geometry detail long ago and abandoned after drives got bigger than 8GB.
Now L-CHS and P-CHS are both logical (not really existing physically,
nevermind that P-) geometries.
Drives use a 16386 cylinder/16 head maximum and BIOS INT13 uses a
1024 cylinder/256 head maximum to expand on an earlier 1024 16 63 limit.
L is for the program interface side of the BIOS, P is for the drive side
(the IDE physical interface) of the BIOS.


Svend Olaf Mikkelsen has a program GB32 that can pinpoint it for you.
http://www.partitionsupport.com/utilities.htm

If you have the problem then the link to M$ should get you sorted.

Thanks so much for your ideas and for the link to the GB32 program.
I'm anxious to try out the utility, but plan to hold off on any
testing until I get some new external storage and (safely) back up my
30gb primary drive.