S
Svend Olaf Mikkelsen
It is a matter of different opinions. Folkert does not accept that I
and several others divide the disk space in units of cylinders, and
count and numbers them.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
It is a matter of different opinions. Folkert does not accept that I
and several others divide the disk space in units of cylinders, and
count and numbers them.
F
Folkert Rienstra
Anyone with eyes to see knows that it was the other way around.
Opinions has nothing whatsoever got to do with it.
It is a matter of what is right and what is wrong.
And rightly so.
You should be an educator, not a witch doctor.
Presenting the problem of who is hiding behind who when it comes
to admitting that CHS is a total figment of imagination and has long
outlived its usefulness. The same people probably, that are behind
the various malware that presents itself as partitioning software,
the disastrous results of their cluelessness you so often have to repair.
And educate the less knowledgeable completely the wrong way.
It is people like you that we have to blame for that when someone
comes along rambling about (non existent) CHS values.
It is this stubbornness that made you careless and use values in
your applications that even the bios documentation says is invalid.
Dividing the disk space in units of cylinders was useful when H*S was
a nice decimal like value like say 1032 and you could use the cylinders
number directly as the capacity of the drive.
Cylinders: 16709 Heads: 255 Sectors: 63 is completely useless in
this regard.
H and S has some usefulness in easily determining partition boundaries
by the eye but when a program like findpart does checks internally already,
printing H and S is of no further use and adding an invalid C is only causing
further confusion.
It is a matter of different opinions.
Opinions has nothing whatsoever got to do with it.
It is a matter of what is right and what is wrong.
Folkert does not accept
And rightly so.
that I
You should be an educator, not a witch doctor.
and several others
Presenting the problem of who is hiding behind who when it comes
to admitting that CHS is a total figment of imagination and has long
outlived its usefulness. The same people probably, that are behind
the various malware that presents itself as partitioning software,
the disastrous results of their cluelessness you so often have to repair.
divide the disk space in units of cylinders, and count and numbers them.
And educate the less knowledgeable completely the wrong way.
It is people like you that we have to blame for that when someone
comes along rambling about (non existent) CHS values.
It is this stubbornness that made you careless and use values in
your applications that even the bios documentation says is invalid.
Dividing the disk space in units of cylinders was useful when H*S was
a nice decimal like value like say 1032 and you could use the cylinders
number directly as the capacity of the drive.
Cylinders: 16709 Heads: 255 Sectors: 63 is completely useless in
this regard.
H and S has some usefulness in easily determining partition boundaries
by the eye but when a program like findpart does checks internally already,
printing H and S is of no further use and adding an invalid C is only causing
further confusion.
F
Folkert Rienstra
Svend Olaf Mikkelsen said:PS. Do not worry about the FAT. FAT is not expected in an NTFS partition.
The "?" indicates that the partition ends after reported disk size.
But then the reported disksize is invalid as it has been derived from
an invalid CHS. There may not be a problem at all as far as FindPart
is concerned since it is flawed at that point.
Also, it is not the CHS that is ending after 'end of disk' but the LBA
end sector (Starting LBA + LBA size, i.e. ----Rel + -----Num).
All the (so called) CHS values that result in over 8GB size are invalid
and should be distrusted. The partition table CHS values as shown by
FindPart are not the actual values but reverse engineered (calculated)
from the RelNum values. The actual C values are limited to 1023.
F
Folkert Rienstra
Thanks for aknowledging in your ever mysterious way that you were
completely wrong about using the CHS values in Int 13-AH=48h
when the result of C*H*S is over 8 GB.
Apology accepted.
There is one line where 'current' and 'mode' are used in the same line,
where it is somewhat unclear what the meaning of the word current is there:
'current' as in 'at this moment' or as in 'Current Translation', the definition.
Nowhere else is that word combination repeated.
It isn't of much use other than that it may signal that the bios is using an-
other geometry translation than the drive's default geometry, if they differ.
You cannot check whether the bios is actually using the same translation as
that it has set on the drive.
completely wrong about using the CHS values in Int 13-AH=48h
when the result of C*H*S is over 8 GB.
Apology accepted.
Svend Olaf Mikkelsen said:I guess the origin is a quote from the ATA 3 document.
There is one line where 'current' and 'mode' are used in the same line,
where it is somewhat unclear what the meaning of the word current is there:
'current' as in 'at this moment' or as in 'Current Translation', the definition.
Nowhere else is that word combination repeated.
Anyway, people who need this information will be able to get it.
It isn't of much use other than that it may signal that the bios is using an-
other geometry translation than the drive's default geometry, if they differ.
You cannot check whether the bios is actually using the same translation as
that it has set on the drive.
J
Joep
Folkert Rienstra said:Thanks for aknowledging in your ever mysterious way that you were
completely wrong about using the CHS values in Int 13-AH=48h
when the result of C*H*S is over 8 GB.
Apology accepted.
What apology?
C
Chris Bailiss
Andy, Thanks for that, very useful.
One question: If my BIOS reports the drive size as 137GB, I presume
that 128GB (Windows definition of a GB) is the largest disk size that
Windows will be able to use too, and that I should take steps to limit
the disk size to that?
All this, of course, once I have retrieved whatever data I can from
the disk.
Thanks,
Chris
One question: If my BIOS reports the drive size as 137GB, I presume
that 128GB (Windows definition of a GB) is the largest disk size that
Windows will be able to use too, and that I should take steps to limit
the disk size to that?
All this, of course, once I have retrieved whatever data I can from
the disk.
Thanks,
Chris
F
Folkert Rienstra
Chris Bailiss said:Andy, Thanks for that,
very useful.
Apparently not.
Judging by your question, you didn't understand a word of it.
" The master drive contained several small logical drives at the beginning
of the drive for different OS installations followed by a 128GB logical
drive for data"
One question: If my BIOS reports the drive size as 137GB, I presume
that 128GB (Windows definition of a GB) is the largest disk size that
Windows will be able to use too, and that I should take steps to limit
the disk size to that?
So, obviously, not.
All this, of course, once I have retrieved whatever data I can from the disk.
Thanks,
Chris
[snip]
C
Chris Bailiss
Sorry, if my question was unclear.
I understand Andy has used a larger drive than 128GB. My question was
really around is it possible to have a whole 200GB drive in one
partition? And is this the typical case?
Thanks,
Chris.
I understand Andy has used a larger drive than 128GB. My question was
really around is it possible to have a whole 200GB drive in one
partition? And is this the typical case?
Thanks,
Chris.
C
Chris Bailiss
Hi again all, and thanks for your replies to date,
I have taken some time to look into exactly what has happened to my
drive (full details of the symptoms of the problem can be found in my
earlier post).
I have not managed to recover much of my data, but have found out a
number of facts which might be useful to others. These were the facts
that I could not find on the net earlier, and inadvertantly led me to
erroneously conclude my system supported the full disk size.
What I have discovered:
To use a hard drive past the 137/128 GB limit (depending on your
definition of a GB) in Windows, the system must be configured to meet
the following requirements (taken from the MS Knowledge Base):
1. A computer with a 48-bit LBA-compatible Basic Input/Output System
(BIOS) installed.
2. A computer with a hard disk that has a capacity of greater than
137 gigabytes (GB).
3. A computer running either Windows 2000 SP3, or Windows XP SP1.
4. You must enable the support in the Windows registry by adding or
changing the EnableBigLba registry value to 1 in the following
registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
Note that step 4 is a manual step, and does NOT occur automatically
when 2000SP3 is installed. Enabling 48-bit LBA support (i.e. setting
the registry key value) in Windows 2000 has to be done manually.
On the other hand, installing XPSP1 does automatically enable 48-bit
LBA support.
My system meets requirements 2, 3 and 4, but not 1.
I find it surprising that the Maxtor Disk Setup Utility (which is
supposed to determine whether the MaxBlast3 DDO Overlap is required)
did not try to install the overlay, nor did it mention that my system
does not support 48-bit LBA. Nor does the documentation (which I did
read thoroughly) mention the exact four requirements I have listed
above (though the setup utility does set the registry key). Unless I
am missing something, this seems a very poor piece of software.
From these articles and the help I have received through other peoples
posts, I think I am now in a better position to understand what may
have happened:
1. The drive (Primary Slave) was fine after the XP install had been
completed into the second partition on Primary Master.
2. When Win2000 didn't boot and I ran the win2k repair, it replaced
the XP loader with the 2k one. I didn't boot into XP immediately and
so didn't notice this straight away.
3. I was in 2000 and copied some data into Primary Slave which went
past the 128GB barrier, and seems to have now got put on top of part
of the MFT.
4. I then attempted to go into the XP install, which gave the strange
2000 boot up message, now explained by (2).
5. I then went back into 2000, and the Primary Slave was now broken.
Hence my confusion around the failed XP boot attempt causing the
problem.
While it is nice to now better understand why this probably happened,
unfortunately I am now closer to retrieving my data. I have run a
couple of scans of the drive using the R-Studio recovery program, and
depressingly few real files have turned up. There are a lot of
fragmented/hoax entries.
Svend, if you are reading this, it seems I might not be able to get
Windows to see the entire disk afterall, as per your suggestion.
Though, given what I have described above, it seems unlikely that
there might be any data there anyway?
I am not sure of the best way to proceed. Does anyone have any ideas?
It seems that I might have to resort to trying to retrieve the data
without the MFT structures?
For others who may be reading this in the future, the following
articles / websites that I have used (and that I found useful) are:
Microsoft Knowledge Base Article - 305098
48-Bit LBA Support for ATAPI Disk Drives in Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305098
Microsoft Knowledge Base Article - 303013
How to enable 48-bit Logical Block Addressing support for ATAPI disk
drives in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;EN-US;303013
No doubt Microsoft will change their knowledge base links again in the
future, but hopefully a quick search on the Article Ids should find
them.
The following may also be useful:
48bitLBA.com - Source for 48-bit LBA Information
http://www.48bitlba.com/index.htm
Bios & Windows OS Limitations for ATA Hard Drives
http://www.buildorbuy.org/bioslimits.html
(48bitLBA.com also has a useful little utility on called HDInfo, to
get some status information about your disks, plus whether your system
supports 48-bit LBA or not. It isn't free unfortunately, but costs
only around GBP5).
Thanks for taking the time to read all this!
Chris
I have taken some time to look into exactly what has happened to my
drive (full details of the symptoms of the problem can be found in my
earlier post).
I have not managed to recover much of my data, but have found out a
number of facts which might be useful to others. These were the facts
that I could not find on the net earlier, and inadvertantly led me to
erroneously conclude my system supported the full disk size.
What I have discovered:
To use a hard drive past the 137/128 GB limit (depending on your
definition of a GB) in Windows, the system must be configured to meet
the following requirements (taken from the MS Knowledge Base):
1. A computer with a 48-bit LBA-compatible Basic Input/Output System
(BIOS) installed.
2. A computer with a hard disk that has a capacity of greater than
137 gigabytes (GB).
3. A computer running either Windows 2000 SP3, or Windows XP SP1.
4. You must enable the support in the Windows registry by adding or
changing the EnableBigLba registry value to 1 in the following
registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
Note that step 4 is a manual step, and does NOT occur automatically
when 2000SP3 is installed. Enabling 48-bit LBA support (i.e. setting
the registry key value) in Windows 2000 has to be done manually.
On the other hand, installing XPSP1 does automatically enable 48-bit
LBA support.
My system meets requirements 2, 3 and 4, but not 1.
I find it surprising that the Maxtor Disk Setup Utility (which is
supposed to determine whether the MaxBlast3 DDO Overlap is required)
did not try to install the overlay, nor did it mention that my system
does not support 48-bit LBA. Nor does the documentation (which I did
read thoroughly) mention the exact four requirements I have listed
above (though the setup utility does set the registry key). Unless I
am missing something, this seems a very poor piece of software.
From these articles and the help I have received through other peoples
posts, I think I am now in a better position to understand what may
have happened:
1. The drive (Primary Slave) was fine after the XP install had been
completed into the second partition on Primary Master.
2. When Win2000 didn't boot and I ran the win2k repair, it replaced
the XP loader with the 2k one. I didn't boot into XP immediately and
so didn't notice this straight away.
3. I was in 2000 and copied some data into Primary Slave which went
past the 128GB barrier, and seems to have now got put on top of part
of the MFT.
4. I then attempted to go into the XP install, which gave the strange
2000 boot up message, now explained by (2).
5. I then went back into 2000, and the Primary Slave was now broken.
Hence my confusion around the failed XP boot attempt causing the
problem.
While it is nice to now better understand why this probably happened,
unfortunately I am now closer to retrieving my data. I have run a
couple of scans of the drive using the R-Studio recovery program, and
depressingly few real files have turned up. There are a lot of
fragmented/hoax entries.
Svend, if you are reading this, it seems I might not be able to get
Windows to see the entire disk afterall, as per your suggestion.
Though, given what I have described above, it seems unlikely that
there might be any data there anyway?
I am not sure of the best way to proceed. Does anyone have any ideas?
It seems that I might have to resort to trying to retrieve the data
without the MFT structures?
For others who may be reading this in the future, the following
articles / websites that I have used (and that I found useful) are:
Microsoft Knowledge Base Article - 305098
48-Bit LBA Support for ATAPI Disk Drives in Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305098
Microsoft Knowledge Base Article - 303013
How to enable 48-bit Logical Block Addressing support for ATAPI disk
drives in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;EN-US;303013
No doubt Microsoft will change their knowledge base links again in the
future, but hopefully a quick search on the Article Ids should find
them.
The following may also be useful:
48bitLBA.com - Source for 48-bit LBA Information
http://www.48bitlba.com/index.htm
Bios & Windows OS Limitations for ATA Hard Drives
http://www.buildorbuy.org/bioslimits.html
(48bitLBA.com also has a useful little utility on called HDInfo, to
get some status information about your disks, plus whether your system
supports 48-bit LBA or not. It isn't free unfortunately, but costs
only around GBP5).
Thanks for taking the time to read all this!
Chris
F
Folkert Rienstra
Joep said:What apology?
Exactly.
S
Svend Olaf Mikkelsen
I have taken some time to look into exactly what has happened to my
drive (full details of the symptoms of the problem can be found in my
earlier post).
Nice.
1. A computer with a 48-bit LBA-compatible Basic Input/Output System
(BIOS) installed.
Not needed I guess, if the disk is set to none in BIOS (not possible
for boot disks. (In that case one may be able to set a smaller size in
BIOS, if one knows exactly what one is doing).
4. You must enable the support in the Windows registry by adding or
changing the EnableBigLba registry value to 1 in the following
registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
You could try that. Although when I did it, the Disk Manager still
showed strange partition interpretation, but that may be another
problem. Do however of course not write to the disk.
Svend, if you are reading this, it seems I might not be able to get
Windows to see the entire disk afterall, as per your suggestion.
Though, given what I have described above, it seems unlikely that
there might be any data there anyway?
It seems likely that the beginning of the Master File Table was
overwritten, but if the backup boot sector is available, the MFT file
record mirror may be located, with exact location of the MFT.
My guess would be that current disk managers do not support disks
larger than 128 GB, and that strange behavior can occur if it is
attempted.
S
Svend Olaf Mikkelsen
There is one line where 'current' and 'mode' are used in the same line,
where it is somewhat unclear what the meaning of the word current is there:
'current' as in 'at this moment' or as in 'Current Translation', the definition.
Nowhere else is that word combination repeated.
I will assume that the device you wrote this number to had only room
for 1 bit, and you then think larger numbers than 1 does not exist.
There are 4, of which 3 happens to be one for each of the CTM: values
in the Findpart output.
J
Joep
Folkert Rienstra said:Exactly.
No not. Apology for what?
A
Andy
Hi again all, and thanks for your replies to date,
I have taken some time to look into exactly what has happened to my
drive (full details of the symptoms of the problem can be found in my
earlier post).
I have not managed to recover much of my data, but have found out a
number of facts which might be useful to others. These were the facts
that I could not find on the net earlier, and inadvertantly led me to
erroneously conclude my system supported the full disk size.
What I have discovered:
To use a hard drive past the 137/128 GB limit (depending on your
definition of a GB) in Windows, the system must be configured to meet
the following requirements (taken from the MS Knowledge Base):
1. A computer with a 48-bit LBA-compatible Basic Input/Output System
(BIOS) installed.
In practice I have found this to be a minor issue, only affecting
situations where the BIOS is used to access the hard drive, such as
running Partition Magic under DOS, or during the boot up phase of
Windows 2000 or XP where ntdetect.com and ntldr use the BIOS to access
the logical drive of the OS installation.
2. A computer with a hard disk that has a capacity of greater than
137 gigabytes (GB).
3. A computer running either Windows 2000 SP3, or Windows XP SP1.
4. You must enable the support in the Windows registry by adding or
changing the EnableBigLba registry value to 1 in the following
registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
Note that step 4 is a manual step, and does NOT occur automatically
when 2000SP3 is installed. Enabling 48-bit LBA support (i.e. setting
the registry key value) in Windows 2000 has to be done manually.
On the other hand, installing XPSP1 does automatically enable 48-bit
LBA support.
My system meets requirements 2, 3 and 4, but not 1.
I find it surprising that the Maxtor Disk Setup Utility (which is
supposed to determine whether the MaxBlast3 DDO Overlap is required)
did not try to install the overlay, nor did it mention that my system
does not support 48-bit LBA. Nor does the documentation (which I did
read thoroughly) mention the exact four requirements I have listed
above (though the setup utility does set the registry key). Unless I
am missing something, this seems a very poor piece of software.
From these articles and the help I have received through other peoples
posts, I think I am now in a better position to understand what may
have happened:
1. The drive (Primary Slave) was fine after the XP install had been
completed into the second partition on Primary Master.
2. When Win2000 didn't boot and I ran the win2k repair, it replaced
the XP loader with the 2k one. I didn't boot into XP immediately and
so didn't notice this straight away.
Did you reapply SP4 after repairing Windows 2000?
3. I was in 2000 and copied some data into Primary Slave which went
past the 128GB barrier, and seems to have now got put on top of part
of the MFT.
In you initial message you stated that the slave drive was fine after
you repaired the Windows 2000 installation. Did you run chkdsk to
determine this?
F
Folkert Rienstra
Chris Bailiss said:Sorry, if my question was unclear.
I understand Andy has used a larger drive than 128GB. My question was
really around is it possible to have a whole 200GB drive in one partition?
And is this the typical case?
Thanks,
Chris.
The 48-bit LBA-addressing problem is an (IDE) hardware problem only,
expanding from 28-bits to 48-bits, limited therefor to bios and drivers
(or bridge FW) not partition sizes. Logical LBA addresses have been
64-bit for far longer. Otoh, partitioning software will be limited by
what bios/driver/FW can see and 32-bit entries in the partition tables.
F
Folkert Rienstra
Alexander Grigoriev said:IIRC, MS kludgebase article says that to enable BIG ATA, Windows also checks
if the BIOS supports BigATA.
Hhow does one check that the BIOS supports BigATA?
But I don't know if it is also true for disks "hidden" from BIOS.
Which may prove a bit difficult, without a bios device number?
F
Folkert Rienstra
Chris Bailiss said:Hi again all, and thanks for your replies to date,
I have taken some time to look into exactly what has happened to my
drive (full details of the symptoms of the problem can be found in my
earlier post).
I have not managed to recover much of my data, but have found out a
number of facts which might be useful to others. These were the facts
that I could not find on the net earlier, and inadvertantly led me to
erroneously conclude my system supported the full disk size.
What I have discovered:
To use a hard drive past the 137/128 GB limit (depending on your
definition of a GB) in Windows, the system must be configured to meet
the following requirements (taken from the MS Knowledge Base):
1. A computer with a 48-bit LBA-compatible Basic Input/Output System
(BIOS) installed.
Not necessarily:
"Not. I used to run two 160GB drives on a socket 370 motherboard
with a BIOS that recognized only 137GB. The master drive contained
several small logical drives at the beginning of the drive for different
OS installations followed by a 128GB logical drive for data. "
2. A computer with a hard disk that has a capacity of greater than
137 gigabytes (GB).
Yes, it is a tad hard to use a hard drive past the 137/128 GB limit when
it is smaller than that.
3. A computer running either Windows 2000 SP3, or Windows XP SP1.
4. You must enable the support in the Windows registry by adding or
changing the EnableBigLba registry value to 1 in the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
Apparently that is only necessary when used on the MoBo Chipset IDE.
Note that step 4 is a manual step, and does NOT occur automatically
when 2000SP3 is installed. Enabling 48-bit LBA support (i.e. setting
the registry key value) in Windows 2000 has to be done manually.
On the other hand, installing XPSP1 does automatically enable 48-bit
LBA support.
My system meets requirements 2, 3 and 4, but not 1.
I find it surprising that the Maxtor Disk Setup Utility (which is
supposed to determine whether the MaxBlast3 DDO Overlap is required)
did not try to install the overlay, nor did it mention that my system
does not support 48-bit LBA.
That may actually be a bit hard to find out (although not impossible).
Nor does the documentation (which I did read thoroughly) mention the
exact four requirements I have listed above
Now, isn't that strange when the only operating systems in the world are
windows and windows and windows.
(though the setup utility does set the registry key). Unless I
am missing something, this seems a very poor piece of software.
Then let's keep it to that you are missing something.
From these articles and the help I have received through other peoples
posts, I think I am now in a better position to understand what may
have happened:
1. The drive (Primary Slave) was fine after the XP install had been
completed into the second partition on Primary Master.
2. When Win2000 didn't boot and I ran the win2k repair, it replaced
the XP loader with the 2k one. I didn't boot into XP immediately and
so didn't notice this straight away.
3. I was in 2000 and copied some data into Primary Slave which went
past the 128GB barrier, and seems to have now got put on top of part
of the MFT.
You must have been very lucky that the MBR wasn't overwritten first.
I don't think you can't be that lucky, unless NTFS keeps free space
around its files and that that free space just luckily happened to be
at the 128/137GB barrier.
4. I then attempted to go into the XP install, which gave the strange
2000 boot up message, now explained by (2).
5. I then went back into 2000, and the Primary Slave was now broken.
Hence my confusion around the failed XP boot attempt causing the
problem.
[snip]
C
Chris Bailiss
Thanks again Svend,
I think I may have been a bit premature in my description of what
caused the problem.
Following Folkert's assertion that 48-bit LBA is only required for DOS
support of the full drive size, and that Windows 2000SP3+ will support
large LBA even if the BIOS doesn't, I have done some more
investigating.
You will remember in my original post that FindPart reported my OS as
2000 SP4. This is correct, as in Windows itself reports SP4, however,
the Windows repair overwrites new files with older versions. The
windows Atapi driver, Atapi.sys, located at:
WinNt\System32\drivers\Atapi.sys
is one of the files that is overwritten by a pre-SP3 version.
Repaired version: 5.0.2195.1207
SP4 version: 5.0.2195.6699
(NB: File versions are discussed in the MS Knowledge Base:
48-Bit LBA Support for ATAPI Disk Drives in Windows 2000 - Q305098
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305098)
Hence, I have re-applied SP4, since it will happily install over
itself.
This has improved the situation a little, in that the driver now
appears full size (though whether it could reliably write to the full
200GB I am less certain of, I don't know how/if LBA utilises BIOS?).
I have thus re-run:
1) findpart tables results1.txt
Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 1999-2004.
OS: Windows 5.0.2195 Service Pack 4 Partition tables:
Disk: 1 Cylinders: 7299 Heads: 255 Sectors: 63 MB: 57255
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63117258372 57255 0 1 1 7298*254 63 OK OK
Disk: 2 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1 07 63398283417194474 0 1 1 24791*254 63 NB OK
2) findpart findntfs 2 0 1 1 summary results2.txt
FindNTFS, version FP 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2004.
OS: Windows 5.0.2195 Service Pack 4
Disk: 2 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
CHS 0/1/1 LBA: 63
Directories: 281
Files: 1976
Trees: 3
Exe/dll files: 144
Exe/dll files signature: 139
Not referenced files: 9
Cluster KB: 4
MFT cluster no: 4
MFT size: 184010752
MFT cluster bytes: 4096
Listed files MB: 18658
The MFT details reported are now different to the re-application
pre-SP4, though only the same set of files has been discovered.
Again, Svend, if you are reading, does this look better? I would
really appreciate your, or anyone elses suggestions once again.
Many thanks everyone for all of your help so far.
Chris.
I think I may have been a bit premature in my description of what
caused the problem.
Following Folkert's assertion that 48-bit LBA is only required for DOS
support of the full drive size, and that Windows 2000SP3+ will support
large LBA even if the BIOS doesn't, I have done some more
investigating.
You will remember in my original post that FindPart reported my OS as
2000 SP4. This is correct, as in Windows itself reports SP4, however,
the Windows repair overwrites new files with older versions. The
windows Atapi driver, Atapi.sys, located at:
WinNt\System32\drivers\Atapi.sys
is one of the files that is overwritten by a pre-SP3 version.
Repaired version: 5.0.2195.1207
SP4 version: 5.0.2195.6699
(NB: File versions are discussed in the MS Knowledge Base:
48-Bit LBA Support for ATAPI Disk Drives in Windows 2000 - Q305098
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305098)
Hence, I have re-applied SP4, since it will happily install over
itself.
This has improved the situation a little, in that the driver now
appears full size (though whether it could reliably write to the full
200GB I am less certain of, I don't know how/if LBA utilises BIOS?).
I have thus re-run:
1) findpart tables results1.txt
Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 1999-2004.
OS: Windows 5.0.2195 Service Pack 4 Partition tables:
Disk: 1 Cylinders: 7299 Heads: 255 Sectors: 63 MB: 57255
-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63117258372 57255 0 1 1 7298*254 63 OK OK
Disk: 2 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1 07 63398283417194474 0 1 1 24791*254 63 NB OK
2) findpart findntfs 2 0 1 1 summary results2.txt
FindNTFS, version FP 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2004.
OS: Windows 5.0.2195 Service Pack 4
Disk: 2 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
CHS 0/1/1 LBA: 63
Directories: 281
Files: 1976
Trees: 3
Exe/dll files: 144
Exe/dll files signature: 139
Not referenced files: 9
Cluster KB: 4
MFT cluster no: 4
MFT size: 184010752
MFT cluster bytes: 4096
Listed files MB: 18658
The MFT details reported are now different to the re-application
pre-SP4, though only the same set of files has been discovered.
Again, Svend, if you are reading, does this look better? I would
really appreciate your, or anyone elses suggestions once again.
Many thanks everyone for all of your help so far.
Chris.
C
Chris Bailiss
Thanks for your reply Andy. My comments are below.
This is indeed interesting. This seems to show Logical Block
Addressing does not use the BIOS to access the drive.
I have also been reading the Intel website about 48-bit LBA support
for large drives, at:
http://support.intel.com/support/chipsets/iaa/sb/CS-009281.htm
This supports what you have said, i.e. Windows 2000 SP4 will already
support the full disk size, and installing extras is only needed for
BIOS-like functionality support (i.e. through DOS).
I hadn't when your message was posted, since Windows reported its
version as SP4. However, following your note I checked the ATAPI
driver (see my other post in this thread from today) and found it had
been downgraded to an earlier, pre SP3 version.
I therefore reinstalled SP4, which enabled full windows support for
the disk size (i.e. it now appears as a 190GB drive) but it still
seems broken (see my other post).
I didn't. I have been cautious in the tools I have used since I did
not want to make any changes to the data on the disk that would
compund the current problem.
I will look into it, since it sounds like a good idea. Are there any
circumstances where it would make changes to the disk?
Thanks for your reply, it has proved very informative!
Chris
Andy said:In practice I have found this to be a minor issue, only affecting
situations where the BIOS is used to access the hard drive, such as
running Partition Magic under DOS, or during the boot up phase of
Windows 2000 or XP where ntdetect.com and ntldr use the BIOS to access
the logical drive of the OS installation.
This is indeed interesting. This seems to show Logical Block
Addressing does not use the BIOS to access the drive.
I have also been reading the Intel website about 48-bit LBA support
for large drives, at:
http://support.intel.com/support/chipsets/iaa/sb/CS-009281.htm
This supports what you have said, i.e. Windows 2000 SP4 will already
support the full disk size, and installing extras is only needed for
BIOS-like functionality support (i.e. through DOS).
Did you reapply SP4 after repairing Windows 2000?
I hadn't when your message was posted, since Windows reported its
version as SP4. However, following your note I checked the ATAPI
driver (see my other post in this thread from today) and found it had
been downgraded to an earlier, pre SP3 version.
I therefore reinstalled SP4, which enabled full windows support for
the disk size (i.e. it now appears as a 190GB drive) but it still
seems broken (see my other post).
In you initial message you stated that the slave drive was fine after
you repaired the Windows 2000 installation. Did you run chkdsk to
determine this?
I didn't. I have been cautious in the tools I have used since I did
not want to make any changes to the data on the disk that would
compund the current problem.
I will look into it, since it sounds like a good idea. Are there any
circumstances where it would make changes to the disk?
Thanks for your reply, it has proved very informative!
Chris
C
Chris Bailiss
Folkert Rienstra said:The 48-bit LBA-addressing problem is an (IDE) hardware problem only,
expanding from 28-bits to 48-bits, limited therefor to bios and drivers
(or bridge FW) not partition sizes. Logical LBA addresses have been
64-bit for far longer. Otoh, partitioning software will be limited by
what bios/driver/FW can see and 32-bit entries in the partition tables.
Several people have said this today. All very useful.
One question I am still working through: Does LBA use the BIOS/IDE?
Thanks for the help.
Chris.