Breaking 137GB Barrier 440BX

[Recra]

440BX chipset (EIDE=UDMA2)
AmiBios 3.1 (circa 1999)

Hi,

Apologies for as I already know this will be long..

(Skip straight to *** for main question I'm asking.)

I just picked up a 250GB (P)ATA HDD, (Samsung SP2514N), for this older
computer and scratching my head a bit about the 48-bit LBA 137GB barrier.

I'm good with knowing what is needed to get past 137GB: 48-bit LBA support
in the BIOS (or addon hardware) and patched OS's that will support past
137GB.

First thing I did, of course, was attempt to see if there was a newer BIOS
available, but I had already flashed the last released BIOS (AmiBios 3.1)
for the motherboard years ago. The BIOS has an "enable LBA/Large Mode"
option, but I suspect that is for the old 8GB barrier and not 48-bit LBA.

I sent the motherboard manufacturer an email asking about 48-bit LBA support
and they responded basically that since this particular motherboard has
onboard SCSI, there was no reason to update the BIOS for 48-bit LBA EIDE/ATA
support. Their assumption then (now?) seems to be if anyone was going to
use a big HDD, it would be SCSI.

Well, I do have a SCSI drive in it, but now I also have an EIDE drive -- and
I want to use this EIDE drive.

So, the BIOS thing isn't going to happen, leaving me other choices, and
questions, which I'm starting to investigate:

- Buying an add-on PCI card that would provide 48-bit LBA support. This is
certaintly the most straight-forward (hardware-wise) option and would also
allow for full use of UDMA5 with the 250GB drive, however I can see this
approach turning into a major pain in the ass. These cards, I assume, would
have to have some sort of onboard BIOS that gets called up during boot. So,
with this card, I'm going to have BIOS's coming up all over the place: the
main motherboard BIOS, the SCSI bios, and then this one. I can already see
them tripping over one another. I really don't want to re-cable either as
the way everything is (literally) packed now, moving one just one IDE cable
around is going to be a bitch. Where the 250GB HDD is right now, the cable
just reaches the m/b IDE slot. Getting it to reach a PCI location is going
to require moving SCSI bs around, power around, ect. Plus, I'm not really
wanting to give up an IRQ/PCI slot unless it is a complete last resort.

- BIOS "extensions". I remember many years ago, you could buy a "BIOS on a
(ISA) card" that would either extend the main m/b BIOS or run in place of
it. Anything like this exist today, to do "modern stuff" like get a 48-bit
LBA translator up in memory and cooking? Also seems, if I'm reading right
out there, that there is a "cottage industry" of customized BIOS'ing going
on, giving support beyond where manufacturers leave off. This is all grey
to me, so need to read a lot on it.

- Dynamic Drive Overlays. Yuck, but maybe. This is also a last resort.
I'm planning on putting a few different OS's on the HDD, so can already see
BS problems creeping up between the DDO and multi-OS bootloaders. Years
ago, I used one of these translators for some HDD BS limitation (can't
remember), but it didn't seem to mind sharing the MBR with the OS bootloader
I was using at the time. Brings back memories of the old "Press spacebar to
load from floppy". The overlay ran, then the bootloader, then it would call
up whatever selected -- either win or LILO in the beginning of a Linux part.
It worked then, but I don't trust them today. I bet to give 48-bit LBA
support, its probably too damn big to share with an OS loader.

So... Not sure yet, which I want to do, but I would like to start actually
using the drive already...

I can live with it being just a "137GB drive" for now and use it as such
while continuing to investivate the above approaches, but this leaves me
with one (simple?) question, which I couldn't find a direct answer for:

***

If you don't have 48-bit hardware support, can you use a HDD greater than
137GB as a "137GB drive" -- and later, if you do apply a 48-bit LBA hardware
support, will the unused space appear as "unallocated"? (Assuming you are
within an OS, patched and all, that can support 48-bit LBA)

In other words, if you were to use a 250GB HDD as a "137GB HDD" (because you
don't have 48-bit LBA support), are you just using the first physical 137GB
of that drive versus some geometry bullshit going on where you would
actually be using the whole drive, but it is "acting like 137GB"?

I want to start using the drive now, but want to make sure I'm not screwed
down the road when I decide on a 48-bit LBA approach. I haven't installed
anything, yet, but have poked around the drive with various utils. Windows
sees the entire drive (unallocated) as 131GB (decimal), while Linux can see
the entire (unallocated) drive as 238GB (decimal). Now, I know just
because Linux can see the whole drive, doesn't mean anything. I know better
than to install anything beyond 137GB.

....but the first 137GB should be "fair game" for now?
....and the remaing 113GB usable after deciding on a 48-bit LBA approach,
without impacting anything already installed?

Thanks!

 

[Rod Speed]

440BX chipset (EIDE=UDMA2)
AmiBios 3.1 (circa 1999)

Apologies for as I already know this will be long..

(Skip straight to *** for main question I'm asking.)

I just picked up a 250GB (P)ATA HDD, (Samsung SP2514N), for this
older computer and scratching my head a bit about the 48-bit LBA
137GB barrier.

I'm good with knowing what is needed to get past 137GB: 48-bit LBA
support in the BIOS (or addon hardware) and patched OS's that will
support past 137GB.

First thing I did, of course, was attempt to see if there was a newer
BIOS available, but I had already flashed the last released BIOS
(AmiBios 3.1) for the motherboard years ago. The BIOS has an "enable
LBA/Large Mode" option, but I suspect that is for the old 8GB barrier
and not 48-bit LBA.

I sent the motherboard manufacturer an email asking about 48-bit LBA
support and they responded basically that since this particular
motherboard has onboard SCSI, there was no reason to update the BIOS
for 48-bit LBA EIDE/ATA support. Their assumption then (now?) seems
to be if anyone was going to use a big HDD, it would be SCSI.

Or they are bullshitting and they were too lazy to bother.

Well, I do have a SCSI drive in it, but now I also have
an EIDE drive -- and I want to use this EIDE drive.

So, the BIOS thing isn't going to happen,

There are a few after market bios around,
likely one would support that board.

leaving me other choices, and questions, which I'm starting to
investigate:

- Buying an add-on PCI card that would provide 48-bit LBA support.
This is certaintly the most straight-forward (hardware-wise) option
and would also allow for full use of UDMA5 with the 250GB drive,
however I can see this approach turning into a major pain in the ass.

Cant see that last. A minor pain in the arse at most.

These cards, I assume, would have to have some sort of
onboard BIOS that gets called up during boot. So, with this
card, I'm going to have BIOS's coming up all over the place:

Nope, just one more.

the main motherboard BIOS, the SCSI bios, and then
this one. I can already see them tripping over one another.

They dont in practice.

I really don't want to re-cable either as the way
everything is (literally) packed now, moving one
just one IDE cable around is going to be a bitch.

You can ignore that cable and add a new one with the card.

Where the 250GB HDD is right now, the cable just reaches the
m/b IDE slot. Getting it to reach a PCI location is going to
require moving SCSI bs around, power around, ect.

See above.

Plus, I'm not really wanting to give up an IRQ/PCI
slot unless it is a complete last resort.

It is the most effective way to get 48 bit LBA support if you
dont want to go the after market motherboard bios route.

- BIOS "extensions". I remember many years ago, you could buy a
"BIOS on a (ISA) card" that would either extend the main m/b BIOS
or run in place of it. Anything like this exist today, to do "modern
stuff" like get a 48-bit LBA translator up in memory and cooking?

Havent noticed any, but then I havent looked for them either.

And you'll still lose a card slot.

Also seems, if I'm reading right out there, that there is
a "cottage industry" of customized BIOS'ing going on,
giving support beyond where manufacturers leave off.

Yes, thats the after market motherboard bios I referred to above.

This is all grey to me, so need to read a lot on it.

All you need to know is if your motherboard is supported.

- Dynamic Drive Overlays. Yuck, but maybe.

Not viable with XP.

This is also a last resort. I'm planning on putting a few different OS's
on the HDD, so can already see BS problems creeping up between
the DDO and multi-OS bootloaders. Years ago, I used one of
these translators for some HDD BS limitation (can't remember),

One of the earlier drive size limits.

but it didn't seem to mind sharing the MBR
with the OS bootloader I was using at the time.

Yep, they were reasonably effective.

Brings back memories of the old "Press spacebar to load from floppy".
The overlay ran, then the bootloader, then it would call up whatever
selected -- either win or LILO in the beginning of a Linux part. It
worked then, but I don't trust them today. I bet to give 48-bit LBA
support, its probably too damn big to share with an OS loader.

Its not a size problem. And there is no problem with size anyway.

The more fundamental problem is that you cant use them with XP.

So... Not sure yet, which I want to do, but I
would like to start actually using the drive already...

I can live with it being just a "137GB drive" for now and
use it as such while continuing to investivate the above
approaches, but this leaves me with one (simple?)
question, which I couldn't find a direct answer for:

If you don't have 48-bit hardware support, can you use a HDD greater
than 137GB as a "137GB drive" -- and later, if you do apply a 48-bit
LBA hardware support, will the unused space appear as "unallocated"?

Only if you partition it initially so that you have
a 137G partition on the front of the drive.

If you dont do that, it will likely appear to be 250G
and will wrap around at the 137GB level and stomp
over the data at the front of the drive.

(Assuming you are within an OS, patched
and all, that can support 48-bit LBA)

In other words, if you were to use a 250GB HDD as a "137GB HDD"
(because you don't have 48-bit LBA support), are you just using the
first physical 137GB of that drive versus some geometry bullshit
going on where you would actually be using the whole drive, but it is
"acting like 137GB"?

Yes, if you do it correctly.

I want to start using the drive now, but want to make sure I'm not
screwed down the road when I decide on a 48-bit LBA approach.

You can get screwed before that with that wrap around problem.

I haven't installed anything, yet, but have poked around the drive
with various utils. Windows sees the entire drive (unallocated)
as 131GB (decimal), while Linux can see the entire (unallocated)
drive as 238GB (decimal).

Yes, its a Win problem, doesnt affect Linux.

Now, I know just because Linux can see the
whole drive, doesn't mean anything. I know
better than to install anything beyond 137GB.

Its quite safe to partition the drive in linux, have
the win partition on the front of the drive, within
the 137G level, use the rest for Linux.

...but the first 137GB should be "fair game" for now?
...and the remaing 113GB usable after deciding on a 48-bit
LBA approach, without impacting anything already installed?

Yes, but you can also keep Win on the front
of the drive and use the rest for Linux too.

 

[Peter]

Just patch your OS and fill up drive with nonimportant files to its full
capacity. Then check if there is any corruption. If none, then you should be
fine.

 

[Recra]

Hi, thanks for the info.

(Snipping just to clean up.)

Since the last post, I threw a quick Linux install on the drive mainly to
just start poking around from inside it.

Based on your reply, along with some further reading, it seems my assumption
of the 48-bit LBA deal isn't really that big of a deal (?)

I was under the assumption that it was going to be a hardware problem
"through and through" with every OS, but if it becomes transparent once the
Linux kernel is up and kicking then that'll work beautifully.

Wasn't looking to make one big 250GB C:\ ,anyway, as the main use for that
computer will be network file storage and piddly daemon LAN stuff to get to
with laptops.

I would like to have a small XP partition though, for a few apps that
require XP. In addition, I also want to bring a Win98 part over as well
for it has a few games (they only run under Win98) that I piddle with from
time to time.

So, a (Win98) FAT32 and an (WinXP) NTFS should be safe, as long as both
reside within the first 137GB. (They'll be well inside, probably even
within the first 40GB.) ...and the rest is fair game to dice up into
(Linux) ext3fs's ? If so that'll work. Nice big playground to do a Linux
install "the right way". I.e, I'll be making seperate partitions for
various data types that I want to samba, making "/home" a seperate partition
so "upgrading" (or even changing distros) in the future will be less
painful, ect.

Thanks!

 

[Rod Speed]

Hi, thanks for the info.

(Snipping just to clean up.)

Since the last post, I threw a quick Linux install on the
drive mainly to just start poking around from inside it.

Based on your reply, along with some further reading, it seems my
assumption of the 48-bit LBA deal isn't really that big of a deal (?)

Yeah, I've never seen a very clear explaination of what JUST
the lack of 48 bit LBA support in the bios produces if you do
use an OS which has 48 bit LBA support enabled in it.

I suspect that it might well just be a few quirks like the drive
not showing up as full sized in Disk Management etc with XP.

And like Pete said, its trivial to check that it doesnt wrap around.

I was under the assumption that it was going to be a hardware problem
"through and through" with every OS, but if it becomes transparent
once the Linux kernel is up and kicking then that'll work beautifully.

Yeah, its not a Linux problem.

Wasn't looking to make one big 250GB C:\ ,anyway, as
the main use for that computer will be network file storage
and piddly daemon LAN stuff to get to with laptops.

I would like to have a small XP partition
though, for a few apps that require XP.

Guaranteed to be fine if that partition is in the first 137GB of the drive.

In addition, I also want to bring a Win98 part over as
well for it has a few games (they only run under Win98)
that I piddle with from time to time.

48 bit LBA support is problematical in Win98 but its trivially kludgeable.
http://www.48bitlba.com/index.htm

So, a (Win98) FAT32 and an (WinXP) NTFS should
be safe, as long as both reside within the first 137GB.
Yep.

(They'll be well inside, probably even within the first 40GB.)
...and the rest is fair game to dice up into (Linux) ext3fs's ?
Yep.

If so that'll work.
Yep.

Nice big playground to do a Linux install "the right way". I.e, I'll
be making seperate partitions for various data types that I want
to samba, making "/home" a seperate partition so "upgrading"
(or even changing distros) in the future will be less painful, ect.

Yep, that's guaranteed to work fine.

 

[Recra]

Just patch your OS and fill up drive with nonimportant files to its full
capacity. Then check if there is any corruption. If none, then you should be
fine.

That is a good idea, thanks. I think, if for anything else just a little
re-assurance, I will do just that before start putting the drive together
"for real".

PartitionMagic 8, running from a different HDD, is already whining about the
few ext3fs partitions that I put on the 250GB HDD. Not sure why, as they
are below 137GB, but... My "gut feeling" is that PM8 won't whine when I
clean the whole slate and try a FAT32 and/or NTFS below 137GB though. I
have no reason to believe that other than a "gut feeling" though. From
there, I'll make the parts past 137GB and start filling 'em up to see what
happens..

Trial and error, aint this so much fun.

 

[Recra]

Yeah, I've never seen a very clear explaination of what JUST
the lack of 48 bit LBA support in the bios produces if you do
use an OS which has 48 bit LBA support enabled in it.

I suspect that it might well just be a few quirks like the drive
not showing up as full sized in Disk Management etc with XP.

And like Pete said, its trivial to check that it doesnt wrap around.


Yeah, its not a Linux problem.



Guaranteed to be fine if that partition is in the first 137GB of the drive.

48 bit LBA support is problematical in Win98 but its trivially kludgeable.
http://www.48bitlba.com/index.htm


Yep, that's guaranteed to work fine.

Thanks! Much appreciated! Things are definetly look brighter now.

Yeah, I'm going to some more trial 'n error before building up "for real".
I'm also in the grey about how "deep" non-support for LBA48 in the BIOS will
go. PartitionMagic 8, running from another HDD, already has been fussing
a little but I kinda expected it going in. No big deal, don't really need
to be "crutched" to PM8 (or even Windows), but it always has been rather
convienent while in Win..

Thanks again!

 

[Recra]

should

That is a good idea, thanks. I think, if for anything else just a little
re-assurance, I will do just that before start putting the drive together
"for real".

PartitionMagic 8, running from a different HDD, is already whining about the
few ext3fs partitions that I put on the 250GB HDD. Not sure why, as they
are below 137GB, but... My "gut feeling" is that PM8 won't whine when I
clean the whole slate and try a FAT32 and/or NTFS below 137GB though. I
have no reason to believe that other than a "gut feeling" though. From
there, I'll make the parts past 137GB and start filling 'em up to see what
happens..

Trial and error, aint this so much fun.

(For whatever it is worth.)

Ok, I did the "test". My "gut feeling" did prove out, when FAT32 and NTFS
were put below 137GB, PM8 stopped whining and wanted to be a player again.

I then put some ext3fs's beyond 137GB, made a quick bash script to do an
incremental file rename and cp loop, and let 'er run . (Probably better way
to do the same thing, but that was the quickest one that came to mind.) I
then went to cut the grass and do a dozen other chores...

Well, after things "filled up", there didn't appear to be any problems at
all. No "looping back below 137GB" or corruption.

However, some bootloader (MBR) issues came up. Googling, I did find a
"fix", but its a kludge.

"Gut feeling" again. I have no problem with "kludging" and certaintly
have done much in the past --- but I really want to do this drive
completetly "the right way" as it is going to be used for a heck of a lot of
data, including system backup images.

Back to looking at and considering adding 48-bit support hardware again,
when a thought came across my mind: I really don't "need" big whopper
partitions for my "system partitions". I don't, relatively, use all that
many different programs. The majority of my HDD space is consumed by media
files.

A couple of years ago I had purchased a drive enclosure kit. (ADS Dual Link
Drive). I bought the enclosure to house a DVD-RW, so I could use with one
of my laptops while on extended work-related trip. The DVD-RW later found
itself in a tower, so the drive enclosure was sitting in a closet since
then.

Hmm. Why not just enclose the Samsung 250GB HDD and use it externally?
Specs say it supports up to ATA133 and ADS's website says it supports
drives over 200GB.

So, that became the new game plan. First, I decided to wipe it completely
clean, so booted up Samsung's "hutil" while it was connected to an IDE port
internally. Began the format function, in which it stated it was doing a
"low level format" (whatever "low level format" is defined as this week)..
Realized right away that it was going to take forever, but I didn't want to
stop it after it was running, so let it. I then went over to a friend's
house to help him put a new alternator in his car...

Hours later, day turns into night, and it finally finishes. No errors. Ran
some of the utils in hutil, since I'm already there, and they all check out
clean.

Took the drive out, mounted the drive into the enclosure, and did a
powerup/shutdown on the computer for good measure (let it run a cycle
without the Samsung, so it can see it itself at least once without the
Samsung, probably not neccessary but figure it couldn't huurt and I really
don't "trust" things to always be automatic without a little "pushing".)

Booted up again and then plugged the enclosure in (enclosure does USB 2.0
and firewire, I'm stuck at using USB 1.0 for now though). PM8 saw it fine
and allowed partitions to be made all across the drive. Its working exactly
like I hoped for!

So, the enclosure is going to be it's permenent home. I can get to over the
LAN, so its basically a "NAS drive" now. Going to pick up a USB2.0/firewire
PCI card, so it will work as USB2.0 next...

Happy with it now. As for internal storage, think I'll just pick up
another drive -- something to give a litte more breathing room for systems,
but it doesn't need to be all that big, either SCSI or IDE. The drive in
there now is SCSI U2W, so may just go with another SCSI. Either way, both
will work find and should be quite cheap for the sizes I had in mind.

Well, all that was quite a bit of time spent, but came out on the other side
learning new things, so guess it was "worth it".

 

[Rod Speed]

Because it cant see the drive properly without 48 bit LBA support.

(For whatever it is worth.)

Ok, I did the "test". My "gut feeling" did prove out,
when FAT32 and NTFS were put below 137GB, PM8
stopped whining and wanted to be a player again.

I then put some ext3fs's beyond 137GB, made a quick bash script
to do an incremental file rename and cp loop, and let 'er run .

You should have done that from XP, Linux has
never had a problem with 48 bit LBA support.

(Probably better way to do the same thing, but that was the
quickest one that came to mind.) I then went to cut the grass

You're not supposed to admit to your drug harvesting activitys.

and do a dozen other chores...

Well, after things "filled up", there didn't appear to be any
problems at all. No "looping back below 137GB" or corruption.

However, some bootloader (MBR) issues came up.
Googling, I did find a "fix", but its a kludge.

"Gut feeling" again. I have no problem with "kludging" and
certaintly have done much in the past --- but I really want to
do this drive completetly "the right way" as it is going to be
used for a heck of a lot of data, including system backup images.

Back to looking at and considering adding 48-bit support hardware
again, when a thought came across my mind: I really don't "need"
big whopper partitions for my "system partitions". I don't, relatively,
use all that many different programs. The majority of my HDD space
is consumed by media files.

A couple of years ago I had purchased a drive enclosure kit.
(ADS Dual Link Drive). I bought the enclosure to house a
DVD-RW, so I could use with one of my laptops while on
extended work-related trip. The DVD-RW later found itself in a
tower, so the drive enclosure was sitting in a closet since then.

Hmm. Why not just enclose the Samsung
250GB HDD and use it externally?

That generally sees a rather poorer drive reliability.

There's a reason even Seagate only have a 1 year warranty on theirs.

Specs say it supports up to ATA133 and ADS's
website says it supports drives over 200GB.

So, that became the new game plan. First, I decided to
wipe it completely clean, so booted up Samsung's "hutil"
while it was connected to an IDE port internally.

You should have used their clearhdd for that.

Began the format function, in which it stated it was doing a "low
level format" (whatever "low level format" is defined as this week)..

Basically adds any new bads found to the bad sector list.

Realized right away that it was going to take forever, but I didn't
want to stop it after it was running, so let it. I then went over to
a friend's house to help him put a new alternator in his car...

Hours later, day turns into night, and it finally finishes.

Yeah, can take a while with modern big drives.

No errors. Ran some of the utils in hutil, since
I'm already there, and they all check out clean.

Took the drive out, mounted the drive into the enclosure, and did a
powerup/shutdown on the computer for good measure (let it run a cycle
without the Samsung, so it can see it itself at least once without the
Samsung, probably not neccessary but figure it couldn't huurt and I
really don't "trust" things to always be automatic without a little
"pushing".)

Booted up again and then plugged the enclosure in (enclosure does
USB 2.0 and firewire, I'm stuck at using USB 1.0 for now though).
PM8 saw it fine and allowed partitions to be made all across the drive.

Its generally better to use XP for that.

Its working exactly like I hoped for!

So, the enclosure is going to be it's permenent home. I can get to
over the LAN, so its basically a "NAS drive" now. Going to pick up
a USB2.0/firewire PCI card, so it will work as USB2.0 next...

 

[Mike Tomlinson]

- Buying an add-on PCI card that would provide 48-bit LBA support.

Best option, but unattractive to you.

- BIOS "extensions". I remember many years ago, you could buy a "BIOS on a
(ISA) card" that would either extend the main m/b BIOS or run in place of
it. Anything like this exist today, to do "modern stuff" like get a 48-bit
LBA translator up in memory and cooking?
No.

- Dynamic Drive Overlays. Yuck, but maybe.

Don't go there. Just don't.

If you don't have 48-bit hardware support, can you use a HDD greater than
137GB as a "137GB drive"
Yes.

-- and later, if you do apply a 48-bit LBA hardware
support, will the unused space appear as "unallocated"?

Pass. Probably, but you'd be very wise to take a backup before
attempting to partition and use it.

I want to start using the drive now, but want to make sure I'm not screwed
down the road when I decide on a 48-bit LBA approach.

You don't _need_ 48-bit hardware (BIOS) support to use a >137Gb drive if
you're not going to boot off it. As long as your OS has 48-bit LBA
support built into its IDE drivers, you can use a large drive as long as
you're happy to continue booting off a smaller disk.

Install the new disk and configure it in the BIOS as "None" or "Not
Installed". The BIOS IDE scan may lock up if you don't do this. Ensure
your OS has 48-bit LBA installed and enabled - see www.48bitlba.com for
details on how to do this and a test utility (EnableBigLba.exe) for
Windows. All modern Linux kernels support 48-bit.

Use Disk Management in Windows and your preferred tools in Linux to
partition and format the drive. It can then be used normally.

Be warned that if you reinstall your OS or apply any patches or fixes
that disable 48-bit LBA, the data on your large disk will be at serious
risk. It may take only one write to scramble the partition table and
lose all the data.

 

[Folkert Rienstra]

Best option, but unattractive to you.

No.

They used to call them "Dynamic Drive Overlays".

Don't go there. Just don't.

Works fine.
Just know how to reinstall one or run it from an emergency floppy when the shit hits.

Pass. Probably,

Not, unless it was partitioned by an app that is not using the bios
to size the disk. Free space will be related to what the app can see.
If 48-bit LBA support is added the free space as recorded in the
partition tables need adjustment.

but you'd be very wise to take a backup before attempting to partition and use it.

You don't _need_ 48-bit hardware (BIOS) support to use a >137Gb drive if
you're not going to boot off it.

Will boot fine without it too if the primary partition is 137GB and even if
it is bigger but at the very small risk that a file that needs access before
the drivers are running can not be accessed. Usually that's not a problem.

 

[Rod Speed]

Best option, but unattractive to you.

Don't go there. Just don't.

Pass. Probably, but you'd be very wise to take a
backup before attempting to partition and use it.

You don't _need_ 48-bit hardware (BIOS) support to use a >137Gb
drive if you're not going to boot off it. As long as your OS has 48-bit
LBA support built into its IDE drivers, you can use a large drive as
long as you're happy to continue booting off a smaller disk.

Install the new disk and configure it in the BIOS as "None" or "Not
Installed". The BIOS IDE scan may lock up if you don't do this.

Nope, that was the seen with the 32G limit that
was the result of a wart in the Award bios.

Ensure your OS has 48-bit LBA installed and enabled - see
www.48bitlba.com for details on how to do this and a test utility
(EnableBigLba.exe) for Windows. All modern Linux kernels support 48-bit.

Use Disk Management in Windows and your preferred tools in Linux
to partition and format the drive. It can then be used normally.

Be warned that if you reinstall your OS or apply any patches or
fixes that disable 48-bit LBA, the data on your large disk will be
at serious risk.

The best way around that its to slipstream
48 bit LBA support onto the XP distribution CD.

 

[Mike Tomlinson]

As long as your OS has 48-bit LBA support built into its IDE drivers, you can
use a large drive as long as you're happy to continue booting off a smaller

disk.

Nonsense.[/QUOTE]

Well, come on then Mr Personality. Share the benefit of your vast
experience with us lesser mortals and tell us _why_ it's "nonsense".

 

[Mike Tomlinson]

Nope, that was the seen with the 32G limit that
was the result of a wart in the Award bios.

You're talking complete shit as usual, Roddles. I have a 250GB drive on
a 440BX board with AMI BIOS here. The BIOS disk scan locks up hard if
the drive is configured as anything other than "None" in the IDE device
listing, because the BIOS code can't cope with very large drives.

The machine boots off an 8Gb disk, and Windows 2000 (with 48 bit LBA
enabled) and Linux can see and use the full capacity of the 250Gb drive
connected to the secondary IDE with no problems.

 

[Folkert Rienstra]

You're talking complete shit as usual, Roddles. I have a 250GB drive on
a 440BX board with AMI BIOS here. The BIOS disk scan locks up hard if
the drive is configured as anything other than "None" in the IDE device
listing,

because the BIOS code can't cope with very large drives.

Which is probably for drives even below 137GB.
Bioses that don't support drives over 137GB will see the drive as 137GB.
They are blissfully unaware of the large drive size specification words in
the drive's identification sector.

 

[Folkert Rienstra]

Well, come on then Mr Personality. Share the benefit of your vast
experience with us lesser mortals and tell us _why_ it's "nonsense".

Nope, it was clear enough when left in the context that you willfully snipped.

 

[Rod Speed]

You're talking complete shit as usual, Roddles.

We'll see, Mikey.

I have a 250GB drive on a 440BX board with AMI BIOS here.
The BIOS disk scan locks up hard if the drive is configured as
anything other than "None" in the IDE device listing, because
the BIOS code can't cope with very large drives.

Nothing to do with 48 bit LBA support.

The machine boots off an 8Gb disk, and Windows 2000 (with 48 bit
LBA enabled) and Linux can see and use the full capacity of the
250Gb drive connected to the secondary IDE with no problems.

Irrelevant to what was being discussed,
your stupid pig ignorant claim about lockups.

 

[Mike Tomlinson]

Nope, it was clear enough when left in the context that you willfully snipped.

I didn't "wilfully snip" anything, Folkert. Your paranoia is showing
again. And I still have no idea what you're talking about.

 

[Recra]

LOL, nah, no "pot garden", although that certaintly would be nice.

Yeah, doing the external thing will have some it's own quirks, but has some
of it's own advantages too.

I picked up a USB2/Firewire PCI card yesterday. (The m/b onboard USB was
only USB1.) USB2 is giving a nice performance increase.
Firewire will be nice if I ever want to dump from my digital video camera to
that computer. I usually just dump to a laptop though.

Thing that is proving really great is the "portability". Went around doing
Ghost backups with the other computers. (Picked up a cheap copy of Ghost
2003 when I got the USB2/Firewire card.)

The main use will be media files though. Been bringing my media over from
stuff already stored on other HDD's and from DVD's. Already filled up
~60GB. Fills up quick. I plan on taking the drive with me, with a laptop,
on the road -- so will have all my media.

Thanks for all the great info! Its been a great learning process.

 

[Recra]

Best option, but unattractive to you.


Don't go there. Just don't.


Pass. Probably, but you'd be very wise to take a backup before
attempting to partition and use it.


You don't _need_ 48-bit hardware (BIOS) support to use a >137Gb drive if
you're not going to boot off it. As long as your OS has 48-bit LBA
support built into its IDE drivers, you can use a large drive as long as
you're happy to continue booting off a smaller disk.

Install the new disk and configure it in the BIOS as "None" or "Not
Installed". The BIOS IDE scan may lock up if you don't do this. Ensure
your OS has 48-bit LBA installed and enabled - see www.48bitlba.com for
details on how to do this and a test utility (EnableBigLba.exe) for
Windows. All modern Linux kernels support 48-bit.

Use Disk Management in Windows and your preferred tools in Linux to
partition and format the drive. It can then be used normally.

Be warned that if you reinstall your OS or apply any patches or fixes
that disable 48-bit LBA, the data on your large disk will be at serious
risk. It may take only one write to scramble the partition table and
lose all the data.

Thanks for the info, all good stuff. Yeah, my reading and fiddlin' pretty
much led me in the same direction: if I were to keep the 250GB'er
internally, then just use another drive < 137GB to boot everything from.
While not necessary for Linux for all the reasons mentioned (I did have
Linux installed at one time, using the drive internally, and everything
looked great from within), just to reduce the paranoia factor a bit. The
paranoia-factor was probably ill-founded, but I'm finding it harder and
harder to really "trust" things these days.

Working just fine externally now though, which in the long run will prefer
as it will allow portability of media, archived ISO's, ect. Been doing
backups with Ghost 2003 as well, which the portability was nice to be able
to move the drive around to different computers, plug it in, and then run
Ghost. Went with Ghost 2003 because I found a cheap copy when I bought a
USB2/firewire card and from deja'ing, read that Ghost 2003 would work across
multi-platforms including Win98, while Ghost9 pretty much became crapware.
(Seems like everything Symantec touches eventually turns into sh*tware.)
Also, from deja'ing, saw that Acronis's TrueImage is pretty popular too,
with some advantages over Ghost, so eventually will check that out too.

Thanks for the info!