Nick Holland wrote:
The question is WHICH 137GB limit (or 128GB limit as I'd like to call
it, but even I'm finding myself rounding up to marketing numbers, but
I digress. again).
Touchee. (;> 137, 128, who is counting right? I used allocation space
from disklabel. Now raw or usable, lets not cut hair. (;> I did tests
using sectors, yes, you know the old school way where you don't specify
the size in Mb, or Gb, etc. But provide sector counts, etc.
The bottom line is that if I try to create partitions, and the last one
bigger then what would make the total partitions getting > then 128,
137, pick your number. (;> it will not even format that partition at the
install process. Even less reboot and use it. (;>
What you get are the errors messages, (sorry I can't recall exactly what
they are) you would get when it try to read a sector and can't, but will
retry and then remap it else where and taking it out of service when you
have a drive that start to physically get damage. I am sorry for the
vague description here, I will need to redo it to provide the best
details, but that's how I would best describe it. Memory fail me and
it's been a year already in all fairness. (;>
Just for the records, the disklabel would be as follow with a 160 Gb
Seagate drive in it. If I try to have the i partition use one single
cylinder more, just one, the process will fail very badly. So, here I
use as much as physically possible with full cylinder here. Can I use a
bit more sectors, yes, but as i explain before, I sure choose not to use
1/2 a cylinder to get a few more sectors and what a few more KB worth of
space, for what. Risking to get into trouble down the road. No thanks.
So, below is as much as I was capable of using and get full cylinders as
well on that drive. Anything pass that was a no go. Even after the fact,
trying to create additional space on that drive via newfs, manual mount
and all wasn't successful at all. I would say, just forget it.
# size offset fstype [fsize bsize cpg]
a: 1049328 0 4.2BSD 2048 16384 1
b: 8389584 1049328 swap
c: 312581808 0 unused 0 0
d: 2097648 9438912 4.2BSD 2048 16384 1
e: 20972448 11536560 4.2BSD 2048 16384 1
f: 2097648 32509008 4.2BSD 2048 16384 1
g: 10486224 34606656 4.2BSD 2048 16384 1
h: 2097648 45092880 4.2BSD 2048 16384 1
i: 221244912 47190528 4.2BSD 2048 16384 1
You mention sparc64, which has some "special" limits due to the
brain dead IDE controller on a few sparc systems.
As you say, yes. Brain dead.
On most other IDE controllers, the 128GB limit is just a boot issue,
you can stick a 500GB drive on a pre-LBA48 controller, and it just
works, but don't try to boot beyond 128GB...or 32GB, or 8GB or
whatever your BIOS is limited to. Once you boot, the entire drive
is yours to use as you wish.
On Sparc64, it's not only boot issue however, but usable as well.
Even as a second drive, if you try to use more, it will crap on you,
even if you are lucky to may be in some cases get pass the disklabel and
create a full partition that use all of it. First time it will write to
the disk pass that limit ( actually I can't say if it is dojgn it, or
trying, or what not) it will crash the system.
Here is an example:
wd0 is the boot drive and the wd1 is just one partition as big as
possible here just for fun. The drive in this case is MAXTOR STM3160215A
and is "152627MB, 312581808 sectors" however, you can't newfs it pass this:
# disklabel wd1a
# /dev/rwd1a:
type: ESDI
disk: ESDI/IDE disk
label: MAXTOR STM316021
flags: vendor
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 47957
total sectors: 312581808
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 268435452 0 4.2BSD 2048 16384 1
c: 312581808 0 unused
disklabel: warning, partition a: size % cylinder-size != 0
Below id the dmesg of that system.
OpenBSD 4.5 (GENERIC) #1898: Sat Feb 28 17:42:44 MST 2009
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC
real mem = 536870912 (512MB)
avail mem = 506732544 (483MB)
mainbus0 at root: Sun Netra X1 (UltraSPARC-IIe 500MHz)
cpu0 at mainbus0: SUNW,UltraSPARC-IIe (rev 1.4) @ 500 MHz
cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 256K
external (64 b/l)
psycho0 at mainbus0: SUNW,sabre, impl 0, version 0, ign 7c0
psycho0: bus range 0-0, PCI bus 0
psycho0: dvma map 60000000-7fffffff
pci0 at psycho0
ebus0 at pci0 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00
"dma" at ebus0 addr 0-ffff ivec 0x2a not configured
rtc0 at ebus0 addr 70-71: m5819
power0 at ebus0 addr 2000-2007 ivec 0x23
"SUNW,lomh" at ebus0 addr 8010-8011 ivec 0x2a not configured
com0 at ebus0 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo
com0: console
com1 at ebus0 addr 2e8-2ef ivec 0x2b: ns16550a, 16 byte fifo
"flashprom" at ebus0 addr 0-7ffff not configured
alipm0 at pci0 dev 3 function 0 "Acer Labs M7101 Power" rev 0x00: 74KHz
clock
iic0 at alipm0
"max1617" at alipm0 addr 0x18 skipped due to alipm0 bugs
spdmem0 at iic0 addr 0x54: 128MB SDRAM registered ECC PC133CL2
spdmem1 at iic0 addr 0x55: 128MB SDRAM registered ECC PC133CL2
spdmem2 at iic0 addr 0x56: 128MB SDRAM registered ECC PC133CL2
spdmem3 at iic0 addr 0x57: 128MB SDRAM registered ECC PC133CL2
dc0 at pci0 dev 12 function 0 "Davicom DM9102" rev 0x31: ivec 0x7c6,
address 00:03:ba:0f:e4:2d
amphy0 at dc0 phy 1: DM9102 10/100 PHY, rev. 0
dc1 at pci0 dev 5 function 0 "Davicom DM9102" rev 0x31: ivec 0x7dc,
address 00:03:ba:0f:e4:2e
amphy1 at dc1 phy 1: DM9102 10/100 PHY, rev. 0
ohci0 at pci0 dev 10 function 0 "Acer Labs M5237 USB" rev 0x03: ivec
0x7e4, version 1.0, legacy support
pciide0 at pci0 dev 13 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc3:
DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using ivec 0x7cc for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: <WDC WD400BB-22DEA0>
wd0: 16-sector PIO, LBA, 38166MB, 78165360 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1 at pciide0 channel 1 drive 0: <MAXTOR STM3160215A>
wd1: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
usb at ohci0 not configured
softraid0 at root
bootpath: /p...@1f,0/i...@d,0/d...@0,0
root on wd0a swap on wd0b dump on wd0b
So...sparc64 users will probably need to try to find sub-128G drives
for their machines (or just put a CF-IDE adapter in, boot from flash
and use a non-stupid IDE interface for non-boot partitions). Users
with systems that have BIOS limitations will have to respect that,
though it shouldn't be the installer's problem, as it seems the
installer "Auto"s to small enough root partitions that only a few
old 486 systems with disks they probably couldn't fsck anyway will
have to manually override.
May be it can be done with CF-IDE. I never tried it. (;> So, I can't
speak knowingly about it. It's an idea, but I am not sure that the X1
would/cold use it anyway. I just don't know.
(and I'm not entirely sure I remember what the big disk issue is
with sparc64 systems...guess I need to find out, and put it in
the FAQ so I can look it up next time I forget. :)
I am getting old too, but that's what I recall from above. But I also do
really very clearly that trying to disklabel the drive using all of it,
will not even succeed the install process and doing smaller one and
after th fact trying to use the additional space like I put in the
second example above didn't work either and really put you into trouble
territory.
I will test with the latest snapshot when available on SPARC64, but I
really wonder as the box I could use are remote and obviously, well I
wouldn't want to crash it. Not a big deal in the end anyway, just wonder
what the answer might be.
I will find one that I can do locally in a few days, but wonder if the
above was even possible.
I don't recall haven't seen any records in the sysctl output that show
the BIOS limits, but I sure could be wrong.
You couldn't trust it if it did.
Thanks for the info. Now I know for sure.
Bugs in BIOSs are very, very common. They have one benchmark: can
they boot DOS and Windows...if so, "did our job", the rest is the
problem for those pesky, non-mainstream OSs to take care of.
Back when tom@ did the new boot loader, which removed the 8G boot
limit of the old loader, and did a bunch of other more subtle (but
wonderful) things, we had difficulty finding machines that could
boot beyond 128G. Sure, the BIOSs claimed compatibility, but all
they did is accurately report the size of the drive, most couldn't
actually boot from beyond 128GB. I'm happy to report things are
much better now...it seems newer BIOSs did eventually start to
work as users would assume.
In short: practically, you couldn't trust what the BIOS told you,
you will either have to design conservatively, or test YOUR box
carefully (and hope your spare parts machine is no worse than
your production system!). Non-multiboot users won't have to worry
about it (except on sparc64..and the sparc64 users issues haven't
changed).
And remember: The Auto layout is just a suggested starting point,
nothing mandates using the suggested layout if YOUR situation
overrides the default assumptions.
Personally, I can't imagine there are many applications of 250G
disks where the entire disk needs to or should be allocated. If
you are building a firewall, 8G is still a plenty big chunk of
disk to allocate, and a /lot/ faster to fsck after you trip over
the power cord.
Yes it is just a suggestion. No complain what so ever there. I was just
curious as to if it would try to use space pass limits from BIOS
assuming they could be discover in the first place, witch they can't
based on the answer you provided. So, that answer my question very well.
Thanks Nick!
PS: Who could even possibly think of asking for a GUI installer after
that. I love it!
wait for it. :-/
OK you win again! (;>
Always a pleasure to your any of your post on m...@. I always get
something out of them, even if only a smile at time, it's wort reading. (;>
Best
Daniel
