I put a WD 250GB PATA drive in a laptop whose BIOS does not support 48-bit LBA but is limited to a maximum of 137.4GB. Using EASEUS disk copy, I was able to clone my old 80GB drive onto the new drive (in a USB case). I put the new drive in my laptop and it booted fine, with a partition of 80 GB. Using EASEUS Partition Magic, I was resized the drive C partition to 137.4GB and created a second logical drive E with the other 112.7GB. Microsoft Article ID 305098 says this is the procedure to do if your BIOS is not 48-bit LBA compliant (you also have to set a registry bit called EnableBigLba) and you are running Windows 2000 SP2. However, I am running Windows XP SP3. I could find only one old Microsoft article (303013) that pertains to Windows XP SP1, but that article isn't clear about whether you can use the remaining space. Does anyone know for certain if this approach (two drives, making sure drive C is within the BIOS limitation, and with EnableBigLba enabled) is safe for Windows XP SP3?
Solution
Your C-partition should be smaller than 128GiB - which is 137GB.
Any partitions beyond that won't be bootable, the BIOS will read data when booting and it cannot access anything beyond 128GiB. But once the operating system is loaded, you may be able to access other partitions that are beyond the 128GiB boundary.
So for example, you create a C-partition of say 120GB. You install Windows, it boots fine. Now you enter disk management and at a D-partition spanning the entire drive. Write some data, reboot and see if it still works. In theory it should boot fine and this should work, but you're sort of a test pilot here.
If you try, i'd like to know if it worked out. Backup everything you don't want to loose, though.
Any partitions beyond that won't be bootable, the BIOS will read data when booting and it cannot access anything beyond 128GiB. But once the operating system is loaded, you may be able to access other partitions that are beyond the 128GiB boundary.
So for example, you create a C-partition of say 120GB. You install Windows, it boots fine. Now you enter disk management and at a D-partition spanning the entire drive. Write some data, reboot and see if it still works. In theory it should boot fine and this should work, but you're sort of a test pilot here.
If you try, i'd like to know if it worked out. Backup everything you don't want to loose, though.
sub mesa
Distinguished
- Apr 17, 2009
- 2,914
- 0
- 21,160
Windows XP RTM does NOT support 48-bit LBA (limited to HDDs in 128GiB or 137GB size)
Windows XP SP1 does support 48-bit LBA, so SP2 and SP3 do as well.
If you have SP3, it should be able to support it even though your BIOS has no support. To try this, simply create a second partition that goes beyond 128GiB and see if you can work with it. Don't try to resize the system partition beyond 128GiB however, as the BIOS itself cannot access this when having to load the OS when booting.
In other words, it may be possible for you to overcome this limitation of your motherboard/BIOS and use partitions beyond 128GiB. Theoretically, this should work.
Windows XP SP1 does support 48-bit LBA, so SP2 and SP3 do as well.
If you have SP3, it should be able to support it even though your BIOS has no support. To try this, simply create a second partition that goes beyond 128GiB and see if you can work with it. Don't try to resize the system partition beyond 128GiB however, as the BIOS itself cannot access this when having to load the OS when booting.
In other words, it may be possible for you to overcome this limitation of your motherboard/BIOS and use partitions beyond 128GiB. Theoretically, this should work.
Thanks for the quick reply. I can create partitions that are >137.4GB -- the question is whether it is safe to do so. Windows even lets me partition drive C with the entire 250GB, even though Microsoft Article 305098 says doing so is very unsafe for a non-48-bit LBA compliant BIOS and will result in bad corruption of data, the OS, even the Master Boot Record. I would be much more confident if I could find even one article from Microsoft, a computer manufacturer, a hard drive manufacturer, or a respected technical magazine that says this is safe -- i.e. when the computer BIOS is not 48-bit LBA compliant, partition drive C with less than 137.4GB and create another partition (in my case, Drive E) with all the rest.
Windows XP SP3 does let me do this. Is it safe?
Windows XP SP3 does let me do this. Is it safe?
sub mesa
Distinguished
- Apr 17, 2009
- 2,914
- 0
- 21,160
Your C-partition should be smaller than 128GiB - which is 137GB.
Any partitions beyond that won't be bootable, the BIOS will read data when booting and it cannot access anything beyond 128GiB. But once the operating system is loaded, you may be able to access other partitions that are beyond the 128GiB boundary.
So for example, you create a C-partition of say 120GB. You install Windows, it boots fine. Now you enter disk management and at a D-partition spanning the entire drive. Write some data, reboot and see if it still works. In theory it should boot fine and this should work, but you're sort of a test pilot here.
If you try, i'd like to know if it worked out. Backup everything you don't want to loose, though.
Any partitions beyond that won't be bootable, the BIOS will read data when booting and it cannot access anything beyond 128GiB. But once the operating system is loaded, you may be able to access other partitions that are beyond the 128GiB boundary.
So for example, you create a C-partition of say 120GB. You install Windows, it boots fine. Now you enter disk management and at a D-partition spanning the entire drive. Write some data, reboot and see if it still works. In theory it should boot fine and this should work, but you're sort of a test pilot here.
If you try, i'd like to know if it worked out. Backup everything you don't want to loose, though.
I am hoping someone will chime in with a "here's a great article that really nails this issue." Lots of people want to put large drives into older laptops, so it amazes me there aren't lots of articles on how to solve this problem (since you cannot change the controller card of a laptop!).
From experience, making the Drive C partition >128GB doesn't make it non-bootable. It just (apparently) gets corrupted some time later.
Here is a current snapshot. In my new 250GB drive, Drive C is partitioned to 127GB (as reported by Windows). That seems safe from what I read (Microsoft articles 305098 and 303013), and I've been operating that way for several weeks without incident. However, I have been reluctant to partition the rest of the drive (so my 250GB drive was operating as a 127GB drive). Well, based on Article 305098 (for Windows 2000 SP2), I decided to create a second partition of 104 GB as Drive E. For now, that appears to work, but Drive E is still empty. I'm reluctant to experiment too much on this computer.
However, in another laptop (same model), using a new 160GB drive, I ran some tests to try to crash the OS. First, I partitioned Drive C to 127 GB and put everything else in drive E. I then filled up drive E to within 1 GB of its full capacity, trying to break something. Since the OS never crashed, I then tried to fill up Drive C so the combined total of both drives was >137GB. It didn't crash (but I didn't spend time testing for data corruption).
I then took that 160G drive, deleted Drive E, and repartitioned Drive C to the full capacity of the drive (this is supposed to be unsafe). No problems booting. Next I tried to fill up drive C to get it to crash (I zipped a large folder and then copied the zip file over and over). Well, I got to within 4 GB of its limit, but no crash. Running Defrag, I noticed white spaces (no data) in the middle of the drive. Thinking I should fill in this space (to crash the computer), I ran Defrag (several times as I filled the drive up), but these center-of-the-drive white spaces wouldn't fill in, as the data was moved to the edges of the drive. It left me wondering whether Windows is trying to leave a hole in the middle, under the 137GB BIOS limit, to keep the OS from crashing. No matter how often I ran Defrag, I couldn't get all of the first 137GB to be free of white space. No crashes. I don't know about data corruption though.
These are shots in the dark.
From experience, making the Drive C partition >128GB doesn't make it non-bootable. It just (apparently) gets corrupted some time later.
Here is a current snapshot. In my new 250GB drive, Drive C is partitioned to 127GB (as reported by Windows). That seems safe from what I read (Microsoft articles 305098 and 303013), and I've been operating that way for several weeks without incident. However, I have been reluctant to partition the rest of the drive (so my 250GB drive was operating as a 127GB drive). Well, based on Article 305098 (for Windows 2000 SP2), I decided to create a second partition of 104 GB as Drive E. For now, that appears to work, but Drive E is still empty. I'm reluctant to experiment too much on this computer.
However, in another laptop (same model), using a new 160GB drive, I ran some tests to try to crash the OS. First, I partitioned Drive C to 127 GB and put everything else in drive E. I then filled up drive E to within 1 GB of its full capacity, trying to break something. Since the OS never crashed, I then tried to fill up Drive C so the combined total of both drives was >137GB. It didn't crash (but I didn't spend time testing for data corruption).
I then took that 160G drive, deleted Drive E, and repartitioned Drive C to the full capacity of the drive (this is supposed to be unsafe). No problems booting. Next I tried to fill up drive C to get it to crash (I zipped a large folder and then copied the zip file over and over). Well, I got to within 4 GB of its limit, but no crash. Running Defrag, I noticed white spaces (no data) in the middle of the drive. Thinking I should fill in this space (to crash the computer), I ran Defrag (several times as I filled the drive up), but these center-of-the-drive white spaces wouldn't fill in, as the data was moved to the edges of the drive. It left me wondering whether Windows is trying to leave a hole in the middle, under the 137GB BIOS limit, to keep the OS from crashing. No matter how often I ran Defrag, I couldn't get all of the first 137GB to be free of white space. No crashes. I don't know about data corruption though.
These are shots in the dark.
sminlal
Splendid
- Jul 10, 2009
- 6,357
- 3
- 28,515
It wouldn't surprise me if no mainstream site has covered the issue. Back in the XP SP1 days there weren't any disks that large outside of RAID arrays, so it wasn't a widely-known issue. It really only became an issue about the time Vista came out, and by that time XP SP1 and the issues it solved were old news.
All I can tell you is that the BIOS is ONLY involved in booting the system, and that ONLY involves the boot partition. As long as that partition is within the BIOS limits, and as long as you're using a Windows version that DOES support the extended LBA addressing, you shouldn't have any problems with OTHER partitions beyond the 137GB limit.
All I can tell you is that the BIOS is ONLY involved in booting the system, and that ONLY involves the boot partition. As long as that partition is within the BIOS limits, and as long as you're using a Windows version that DOES support the extended LBA addressing, you shouldn't have any problems with OTHER partitions beyond the 137GB limit.
Well, WD certainly is frustratingly non-committal on this issue -- I've actually gotten better support from Microsoft! I have created two partitions (both under 137.4 GB), Drives C and E. So far, all works fine. I'll post here if this ever causes a problem.
Thanks again for your help!
Thanks again for your help!
sub mesa
Distinguished
- Apr 17, 2009
- 2,914
- 0
- 21,160
If the E partition works on your BIOS, that would mean it uses 48-bit LBA mode to access it. Even though the E partition is less than 128GiB / 137.4GB as you said, it still requires the operating system to map these to "LBA" or Logical Block Addressing; basically your storage begins at LBA 0 and ends with LBA <large number>. Each number represents one sector - or 512 bytes. So your E partition requires the operating system to read from places where your BIOS can't, that means that our little theory worked i'd say.
The E-partition won't be bootable though. But that shouldn't be of concern.
The E-partition won't be bootable though. But that shouldn't be of concern.
sub mesa
Distinguished
- Apr 17, 2009
- 2,914
- 0
- 21,160
"If the E partition works on your BIOS" that's somewhat poorly stated, i meant to say:
"If creating a second partition works, while booting from the first partition on your computer system - which has no support for 48-bit LBA addressing, your operating system successfully uses 48-bit LBA addressing on your 48-bit LBA 'unable' system!".
"If creating a second partition works, while booting from the first partition on your computer system - which has no support for 48-bit LBA addressing, your operating system successfully uses 48-bit LBA addressing on your 48-bit LBA 'unable' system!".
As far as I know, the BIOS has no interaction with (and knows nothing of) drive E (my second partition), but Windows reads and writes to it just fine; also, if I put the hard drive in an external USB case, both partitions (drives) show up. I read some posts on a Dell forum that validate the 2-partition solution with one explanation that if an Operating System file the BIOS needs to read (i.e. NTLDR) gets written beyond where the BIOS is able to read (i.e. 137.4GB), you get a "drive read error." That makes sense, and it shouldn't happen if (as proposed) the Drive C partition is set to 137.4GB (128GB as seen by Explorer) or less. The Microsoft Article 305098 says this can cause data corruption or damage the Master Boot Record.
However, Windows will merrily let you re-size the Drive C partition to the full 250GB, which is a very bad idea when the laptop BIOS cannot support read or write more than 137.4 GB (voice of experience, echoed by what I read on other forums); at first it seems to work fine until one day it doesn't. I've read stories of people sending back their seemingly defective drives for replacement, only to have the same thing happen again.
I'm using the 2-partition solution. I'll post if there are any issues.
However, Windows will merrily let you re-size the Drive C partition to the full 250GB, which is a very bad idea when the laptop BIOS cannot support read or write more than 137.4 GB (voice of experience, echoed by what I read on other forums); at first it seems to work fine until one day it doesn't. I've read stories of people sending back their seemingly defective drives for replacement, only to have the same thing happen again.
I'm using the 2-partition solution. I'll post if there are any issues.
sub mesa
Distinguished
- Apr 17, 2009
- 2,914
- 0
- 21,160
You are totally correct in all you said, including the issue with creating a C-partition that breaks the 128GiB boundary. It may not work later when you defragment an otherwise full drive and parts needed to boot from will be located beyond 128GiB as you said.
The next boundary is there already: 2 terabyte disks are just below the 2TiB boundary where 64-bit LBA is required. I'm not sure about windows support, though i know at least some support it since some Hardware RAID windows drivers support 64-bit LBA.
Right now there's no problem with either new operating systems, but soon with 3TB+ disks older XP systems may be unable to see beyond 2TiB. So the issue repeats itself - no vision at all for scalable software design.
The next boundary is there already: 2 terabyte disks are just below the 2TiB boundary where 64-bit LBA is required. I'm not sure about windows support, though i know at least some support it since some Hardware RAID windows drivers support 64-bit LBA.
Right now there's no problem with either new operating systems, but soon with 3TB+ disks older XP systems may be unable to see beyond 2TiB. So the issue repeats itself - no vision at all for scalable software design.
wuzy
Distinguished
- Jun 1, 2009
- 900
- 0
- 19,010
Now you've mentioned I never thought that the 2TiB limitation on older controllers came from 48-bit LBA. Makes total sense now.
AFAIK Intel ICH9R and beyond had no problem with arrays over 2TiB, and also all the current and last gen. SAS RAID controllers based on PCIe. So it's implied they had 64-bit LBA support long ago.
The same can't be said for nV RAID and a lot of PCI-X based controllers tho. I've seen many have hit that limit already.
[EDITED]And of course all the *nix software RAID solutions had 64-bit LBA addressing long time ago I assume.
AFAIK Intel ICH9R and beyond had no problem with arrays over 2TiB, and also all the current and last gen. SAS RAID controllers based on PCIe. So it's implied they had 64-bit LBA support long ago.
The same can't be said for nV RAID and a lot of PCI-X based controllers tho. I've seen many have hit that limit already.
[EDITED]And of course all the *nix software RAID solutions had 64-bit LBA addressing long time ago I assume.
Here is an update (several months later). I now have six older P3 and P4 laptops, each with the 28-bit address BIOS limitation (137.4GB), and each now upgraded with a WD 160GB, 250GB, or 320GB PATA hard drive -- all have been running without problems for several months. In each case, drive C was partitioned to <=137.4GB (since Windows Explorer thinks 1GB = 2^30, it reports drive C as <=128GB), and the logical Drive E was partitioned with the remaining space (the optical drive is Drive D). The 250GB drives were worked particularly hard, with lots of files being moved around, and with the drive at times being nearly full. Having put this "keep Drive C under the BIOS limit" idea to the full test, I am now very confident with the approach, which has greatly extended the life of these otherwise fine laptops (that originally came with 20 to 40GB hard drives).
Many thanks to those contributing to this forum.
I've endured this saga three times in the past two months. Not fun.
My details... Sony VAIO VGN-FJ171, WinXP Home SP3, Phoenix Bios R009X06 (does anyone know if this supports 48-bit LBA? I can't determine for sure from the BIOS' output). Original 100GB drive was imaged and cloned onto a new Seagate 500GB drive (ST9500420AS). Booted fine from the new drive, then ran GParted to expand the boot partition to the full 500GB capacity. Again, booted fine and ran smoothly... for a couple of weeks. Then disaster : Windows update forced a re-boot, which resulted in black screen before OS load. I almost cried.
I re-did the clone from scratch (using my original 100GB drive image), and everything worked fine again for a few weeks. Then the same disaster. The common thread is that the BIOS only reports 137GB for the size of the new drive.
I just finished going through round #3. This time, I've decided to leave the C: partition at 100GB and created an E: partition from the remaining 400GB of unused space. At first glance, all is good and as expected. Should I be at all concerned that the next Windows update will trigger yet another black screen episode...?
Stay tuned...
My details... Sony VAIO VGN-FJ171, WinXP Home SP3, Phoenix Bios R009X06 (does anyone know if this supports 48-bit LBA? I can't determine for sure from the BIOS' output). Original 100GB drive was imaged and cloned onto a new Seagate 500GB drive (ST9500420AS). Booted fine from the new drive, then ran GParted to expand the boot partition to the full 500GB capacity. Again, booted fine and ran smoothly... for a couple of weeks. Then disaster : Windows update forced a re-boot, which resulted in black screen before OS load. I almost cried.
I re-did the clone from scratch (using my original 100GB drive image), and everything worked fine again for a few weeks. Then the same disaster. The common thread is that the BIOS only reports 137GB for the size of the new drive.
I just finished going through round #3. This time, I've decided to leave the C: partition at 100GB and created an E: partition from the remaining 400GB of unused space. At first glance, all is good and as expected. Should I be at all concerned that the next Windows update will trigger yet another black screen episode...?
Stay tuned...
From what I've read (http://www.48bitlba.com/sataharddrives.htm), the SATA specification is supposed to have native support for 48-bit LBA (as does USB). However, your laptop originally was configured only with a 100GB drive, which doesn't need 48-bits to address all of its space. Since your BIOS reports the large drive only as 137.4GB, Sony must not have enabled 48-bit LBA (which is consistent with the trouble you described). The good news is that you should be able to operate safely with the 100/400 GB split, or else increase Drive C to 128GiB (as reported by Windows Explorer). Try it, and post back whether you have difficulty.
I have the same problem as bob. I have a sony VAIO VGN-FJ with WIN XP 3, same bios (not 48b lba supported) and i installed a 320gb WD HD, and all went great until I did a defrag (perfect disk 10), the system won´t boot any more...... I reinstalled the SO the same result when it boots after the defrag (black screen,). So searching I found the 28 and 48 bit issue.
From the 48bitlba web page
So I think that says it all.
I still have a question, if i keep my 320gb hd and formatted to only 137gb and keep the remaining space unallocated, should be ok?
From the 48bitlba web page
So I think that says it all.
I still have a question, if i keep my 320gb hd and formatted to only 137gb and keep the remaining space unallocated, should be ok?
For 48-bit LBA to work, it MUST be supported in three places - the HDD itself on its controller board, the mobo's HDD controller and its BIOS, and in the OS. ALL SATA systems include 48-bit LBA support in disks and mobo controllers, but not so with IDE systems before a certain time ROUGHLY around 2000. Obviously, though, IDE drives made recently over 137 GB (128 GiB) must have been designed to support 48-bit LBA, just as all SATA drives have been. The potential problem is in the mobo controllers on older systems.
A few above have tried to beat the system by creating a 128 GiB Partition on a larger IDE drive in a machine that does NOT have 48-bit LBA support in its HDD controller, but does have a Windows version with XP SP1 or later that provides support. So the missing element in this combo is solely in the mobo HDD controller. Then they used Windows' tools to Expand the Partition over 128 GiB, which it was happy to do because it is NOT aware of the mobo's limitations.
Now consider what happens during normal use. Windows knows the size of the Partition it is using. It constantly reads from and writes to that "disk" by passing to the mobo disk controller (and hence to the drive) an LBA address for where it wants the data from / to. Somewhere along the way it will happen to try to use a disk location that actually needs more than the old 28 bits in the LBA address - that is, beyond the 128 GiB boundary. But the mobo controller cannot pass on that whole address - it only sends the disk an address of 28 bits with the higher-order bits missing. When that address arrives, to the disk it looks like an address somewhere else on the disk - like quite possibly, at the very beginning where the Root Directory or all the File System data are - and it follows instructions by writing the new data to that location. Presto! Corruption of System Files!
For those who followed the rules and did NOT try to expand the first Partition beyond the 128 GiB (28-bit LBA) limit, it appears that Windows never tries to use an LBA with addresses requiring more than 28 bits, and no such error will ever be generated. So that part works.
Now, the thread above DOES appear to answer a big question I had. If you stick to that 128 GiB limit as you make ALL of several Partitions on a large drive installed in an older system that lacks 48-bit LBA support in its mobo controller, can corruption occur? What I did not know is how Windows and the disk system use the LBA range for any one Partition. I reason as follows:
Option #1: All locations on one hardware HDD are absolute addresses with an LBA the MUST be able to use 48-bit LBA's at all times. So, for example, if you have a 320 GB (~295 GiB) unit with Partitions of 128 GiB, 128 GiB, and 40 GiB, any location in the SECOND or THIRD Partitions must be specified by an LBA that uses more than 28 bits. When Windows tries to do this and the HDD attempts to follow instructions but is given a truncated LBA by the controller's limits, corruption WILL occur eventually.
Option #2: Each of the Partitions is treated as a separate address space extending from 0 to (28-bit max) because Windows already knows that this is the size of the Partition. In requesting disk access, Windows also specifies exactly which disk (i.e., Partition) it means to use. Additionally, the HDD board understands that any LBA it receives is RELATIVE to the start of the Partition it is told to use. So the HDD board itself uses that knowledge to modify the LBA address by adding an offset that is set by the true LBA of the first block of each Partition, and then it uses this corrected LBA to get to the real location on the physical HDD unit. This will never create corruption as long as Windows never generates an LBA larger than the 128 GiB limit (or the lesser limit of the real Partition size). That can be accomplished if the user NEVER creates any Partition over 128 GiB in such a system.
The posts above that say that experience shows any who adhere strictly to the 128 GiB limit in Partition creation on a multi-Partitioned large drive have never seen data corruption. This suggests that Option #2 that I proposed is really how it works, so that this adherence to the rule makes such uses safe. Does anyone have direct knowledge to confirm that?
A few above have tried to beat the system by creating a 128 GiB Partition on a larger IDE drive in a machine that does NOT have 48-bit LBA support in its HDD controller, but does have a Windows version with XP SP1 or later that provides support. So the missing element in this combo is solely in the mobo HDD controller. Then they used Windows' tools to Expand the Partition over 128 GiB, which it was happy to do because it is NOT aware of the mobo's limitations.
Now consider what happens during normal use. Windows knows the size of the Partition it is using. It constantly reads from and writes to that "disk" by passing to the mobo disk controller (and hence to the drive) an LBA address for where it wants the data from / to. Somewhere along the way it will happen to try to use a disk location that actually needs more than the old 28 bits in the LBA address - that is, beyond the 128 GiB boundary. But the mobo controller cannot pass on that whole address - it only sends the disk an address of 28 bits with the higher-order bits missing. When that address arrives, to the disk it looks like an address somewhere else on the disk - like quite possibly, at the very beginning where the Root Directory or all the File System data are - and it follows instructions by writing the new data to that location. Presto! Corruption of System Files!
For those who followed the rules and did NOT try to expand the first Partition beyond the 128 GiB (28-bit LBA) limit, it appears that Windows never tries to use an LBA with addresses requiring more than 28 bits, and no such error will ever be generated. So that part works.
Now, the thread above DOES appear to answer a big question I had. If you stick to that 128 GiB limit as you make ALL of several Partitions on a large drive installed in an older system that lacks 48-bit LBA support in its mobo controller, can corruption occur? What I did not know is how Windows and the disk system use the LBA range for any one Partition. I reason as follows:
Option #1: All locations on one hardware HDD are absolute addresses with an LBA the MUST be able to use 48-bit LBA's at all times. So, for example, if you have a 320 GB (~295 GiB) unit with Partitions of 128 GiB, 128 GiB, and 40 GiB, any location in the SECOND or THIRD Partitions must be specified by an LBA that uses more than 28 bits. When Windows tries to do this and the HDD attempts to follow instructions but is given a truncated LBA by the controller's limits, corruption WILL occur eventually.
Option #2: Each of the Partitions is treated as a separate address space extending from 0 to (28-bit max) because Windows already knows that this is the size of the Partition. In requesting disk access, Windows also specifies exactly which disk (i.e., Partition) it means to use. Additionally, the HDD board understands that any LBA it receives is RELATIVE to the start of the Partition it is told to use. So the HDD board itself uses that knowledge to modify the LBA address by adding an offset that is set by the true LBA of the first block of each Partition, and then it uses this corrected LBA to get to the real location on the physical HDD unit. This will never create corruption as long as Windows never generates an LBA larger than the 128 GiB limit (or the lesser limit of the real Partition size). That can be accomplished if the user NEVER creates any Partition over 128 GiB in such a system.
The posts above that say that experience shows any who adhere strictly to the 128 GiB limit in Partition creation on a multi-Partitioned large drive have never seen data corruption. This suggests that Option #2 that I proposed is really how it works, so that this adherence to the rule makes such uses safe. Does anyone have direct knowledge to confirm that?
Pointertovoid
Distinguished
- Dec 31, 2008
- 327
- 0
- 18,810
Well no, Bios isn't requested to support 48b Lba. Windows 2k and more recent don't rely on the Bios to access disks. The Bios must only launch the boot sector, which must hence reside in the lower 128GiB. Then, you can safely create more volumes in the upper part of the disk.
And there would be many other workarounds, for instance a host driver (Intel Applications Accelerator and some more) that doesn't rely on Bios. This would enable 48b Lba for Win95-98-Me even if the Bios can't.
Adding another controller would suffice just as well, independently of the Mobo's ans Bios' capabilities.
Or even an overlay software, as Western Digital used to provide for free, works perfectly.
-----
As for the 2TiB barrier: the limit is as Windows (Lba coded on 32 bits), sometimes at the hardware (32 bits or 48 bits). The Windows that allow >2TiB are not the 64b versions, but the ones that allow Mpt partitions instead of Mbr partitions. No workaround known, and I fear there is no simple one. It would need to replace (=rewrite properly) Windows files.
And there would be many other workarounds, for instance a host driver (Intel Applications Accelerator and some more) that doesn't rely on Bios. This would enable 48b Lba for Win95-98-Me even if the Bios can't.
Adding another controller would suffice just as well, independently of the Mobo's ans Bios' capabilities.
Or even an overlay software, as Western Digital used to provide for free, works perfectly.
-----
As for the 2TiB barrier: the limit is as Windows (Lba coded on 32 bits), sometimes at the hardware (32 bits or 48 bits). The Windows that allow >2TiB are not the 64b versions, but the ones that allow Mpt partitions instead of Mbr partitions. No workaround known, and I fear there is no simple one. It would need to replace (=rewrite properly) Windows files.
I realize that the BIOS, in the usual sense, is not required to support 48-bit LBA. It's just that so many current mobo's include the HDD controller function in their basic chipset, so quite reasonably they provide the basic coding for those functions in the BIOS chip that serves the whole mobo. That is why many late-90's mobos actually could be updated with revised BIOS's to support 48-bit LBA without replacing the mobo chipset.
I agree that replacing the mobo's built-in HDD controller with another (usually via a PCI board) is a good solution for many systems caught in this dilemma. It happens that this thread began with a laptop owner who could not do that.
I agree that replacing the mobo's built-in HDD controller with another (usually via a PCI board) is a good solution for many systems caught in this dilemma. It happens that this thread began with a laptop owner who could not do that.
Here's a quote from Microsoft article 305098.
Both the Intel Applications Accelerator and WD Bios overlay are obsolete. I could not get the WD bios overlay to work when cloning an existing drive. However, I am happy to report the multi-partition solution continues to work reliably on several P3 and P4 laptops after several months.
I hope Bob or ric_ will post their experience with the multi-partition solution for their Sony laptops with the 137GB Bios limitation and SATA hard drive.
This article (written for Win2K SP2, applicable to XP SP1 or later) affirms the multi-partition solution (drive C <= 128 GiB) and the posts by Sub_mesa, sminlal, and Pointertovoid.
Both the Intel Applications Accelerator and WD Bios overlay are obsolete. I could not get the WD bios overlay to work when cloning an existing drive. However, I am happy to report the multi-partition solution continues to work reliably on several P3 and P4 laptops after several months.
I hope Bob or ric_ will post their experience with the multi-partition solution for their Sony laptops with the 137GB Bios limitation and SATA hard drive.
Update to my original post...
It's been almost a month, and all seems to be working fine. I've done numerous defrag's, applied several OS patches, and installed new software. Every subsequent re-boot has been successful.
So, based on my specific circumstances (i.e., WinXP SP3 and a Vaio BIOS that doesn't recognize SATA drives > 128GB), I have had success in keeping the boot partition at <= 128GB, while allocating the remaining 300+ GB as a second partition.
Thank you, all, for your input and guidance!
Regards,
- Bob -
It's been almost a month, and all seems to be working fine. I've done numerous defrag's, applied several OS patches, and installed new software. Every subsequent re-boot has been successful.
So, based on my specific circumstances (i.e., WinXP SP3 and a Vaio BIOS that doesn't recognize SATA drives > 128GB), I have had success in keeping the boot partition at <= 128GB, while allocating the remaining 300+ GB as a second partition.
Thank you, all, for your input and guidance!
Regards,
- Bob -
pat-hdirad
Distinguished
- Dec 20, 2010
- 1
- 0
- 18,510
Please pardon my ignorance, but I have a very similar setup - Vaio BIOS that doesn't recognize (in my case PATA) drive > 128GB.
Windows Disk Management and Easus Partition Magic as well as BIOS itself all think that the new 320GB drive's total capacity is 128GB.
What tool did you use to create the additional partitions?
Hi,
It's been a while, so you'll have to excuse the vagueness of my response...
I remember using both gParted and built-in Microsoft disk management tools to deal with this. The Microsoft tool was accessible via Control Panel/Administrative Tools/Computer Management/Storage/Disk Management -- As I recall, from here you can create a partition from the unused/unrecognized space on the new drive.
Hope that helps - good luck!
- Bob -
Your BIOS will never see more than 128GB, but Windows and Easeus Partition Master Home Edition should. After cloning the old drive (EASEUS Disk Copy), the new one will start out with the exact same partition size as the old one, and Partition Master should report the rest of the drive as unallocated space. (You then tell Easeus Partition Master to create a new partition to use the remainder of the drive.) If EASEUS cannot see the unallocated space, it could be a Windows issue. Make sure you have the latest service pack installed. Windows 2000 started supporting large drives as of SP2, and XP started supporting large drives as of SP1.
Here is a relevant note from Microsoft.
http://support.microsoft.com/kb/303013
I have been using this dual-partition method on P3 and P4 compaq laptops for over a year now, and it has been smooth sailing! No problems encountered whatsoever.
TRENDING THREADS
-
-
News US sanctions transform China into legacy chip production juggernaut — production jumped 40% in Q1 2024- Started by Admin
- Replies: 33
-
-
-
Question New pc build r9 7900x3d rtx 4080 super no post only ram rgb turns on- Started by Harvey Durward
- Replies: 5
-
RTX 4070 vs RX 7900 GRE faceoff: Which mainstream graphics card is better?
- Started by Admin
- Replies: 71
Facebook
Twitter
Instagram