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!

Recra <(E-Mail Removed)> wrote

> 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.

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.

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!

Recra <(E-Mail Removed)> wrote

> 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.

"Peter" <(E-Mail Removed)> wrote in message
news:Hdc1g.1362$(E-Mail Removed)...
> 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. :-)

"Rod Speed" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Recra <(E-Mail Removed)> wrote
>
> > 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.
>

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" <(E-Mail Removed)> wrote in message
news:e0h1g.3741$(E-Mail Removed)...
>
> "Peter" <(E-Mail Removed)> wrote in message
> news:Hdc1g.1362$(E-Mail Removed)...
> > 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. :-)
>

(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".

Recra <(E-Mail Removed)> wrote
> Recra <(E-Mail Removed)> wrote
>> Peter <(E-Mail Removed)> wrote

>>> 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...

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

>> 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 .

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...

> 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".

In article <pfa1g.6325$(E-Mail Removed)>, Recra
<(E-Mail Removed)> writes

>- 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.

--
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.