Large (3TB) HDD support

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Large (3TB) HDD support

Scott McEachern-2
Hello everyone,

I'm hoping that I'm missing something simple (like usual) and maybe
someone could straighten me out.

I'm trying to add a pair of 3TB drives to my workstation, which I plan
on turning into a ~3TB RAID 1 array, and seem to be having difficulty
realizing the full size of the drives.

The hardware is about a year old, and less than two years old according
to the BIOS date:

bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010
bios0: ASUSTeK Computer INC. M4A785TD-V EVO

(Correction, I've since updated the BIOS to the latest version, just in
case, and it reads like so:

bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010

and it makes no difference.)

(The full dmesg is below, but for now I'll just post the relevant bits.)

The BIOS happily reports the two drives as present and of 3.0TB
capacity.  OpenBSD seems to recognize this as well:

sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD5000AAKS-0, 05.0> SCSI3
0/direct fixed naa.50014ee001cbd923
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
sd1 at scsibus0 targ 1 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
0/direct fixed naa.5000c5004a6e56f1
sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
sd2 at scsibus0 targ 2 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
0/direct fixed naa.5000c5004a5baa2e
sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors

(Note that sd0 is my boot/OS drive, and works just fine.  The two 3TB
drives, sd1 and sd2, will eventually just be used for storage.)

Those numbers look correct, like the OS is properly recognizing the
capacity.  I have a 1.5TB drive in another machine (a six year-old
Pentium 4 no less!) that works fine and looks like this:

wd0: 16-sector PIO, LBA48, 1430799MB, 2930277168 sectors

(Although I should mention that that drive has a couple of <1TB
partitions, so there are no FFS/FFS2 issues.)

I just wanted to get on with my day and not have any fuss, so I issued
an "fdisk -iy sd1" command on the way to disklabel'ing things.  I
suspect that's my error, because fdisk says this:  (I've added some
commas to make for easier reading.)

# fdisk sd1
Disk: sd1       geometry: 364801/255/63 [1,565,565,872 Sectors]
Offset: 0       Signature: 0xAA55
             Starting         Ending         LBA Info:
  #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
  0: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
  1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
  2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
*3: A6      0   1   2 -  97451 165  59 [          64:  1,565,560,705 ]
OpenBSD

Uhm, that doesn't seem right, considering the fdisk output for a 1.5TB
drive looks like this:

# fdisk wd0
Disk: wd0       geometry: 182401/255/63 [2,930,277,168 Sectors]
Offset: 0       Signature: 0xAA55
             Starting         Ending         LBA Info:
  #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
  0: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
  1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
  2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
*3: A6      0   1   2 - 182400 254  63 [          64:  2,930,272,001 ]
OpenBSD

A drive with half the capacity seems to have double the numbers, but not
for geometry.  I suspect that fdisk is lying to me, but I could be wrong.

Let's see what disklabel(8) has to say.  On the 1.5TB drive, it looks
mostly like this (I've snipped some irrelevant partition data and added
commas to make big numbers easier to read):

# disklabel wd0
# /dev/rwd0c:
type: ESDI
disk: ESDI/IDE disk
label: ST31500341AS
duid: dded65e423b05de7
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 182401
total sectors: 2,930,277,168
boundstart: 64
boundend: 2930272065
drivedata: 0

16 partitions: (snipped)
#                size           offset  fstype [fsize bsize  cpg]
   c:       2,930,277,168                0  unused

On the new 3TB drive, it looks like this:

# disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: ST3000DM001-9YN1
duid: 0000000000000000
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 364801
total sectors: 5,860,533,168
boundstart: 64
boundend: 1565560769
drivedata: 0

16 partitions:
#                size           offset  fstype [fsize bsize  cpg]
   c:       5,860,533,168                0  unused

Wait a minute here... disklabel seems to have correct data (ignoring the
duid).  I'll bet I'm failing at grade four math, but that looks roughly
like a 3TB drive.

So while I'm wondering about going back to grade school, I try creating
one big partition on the new 3TB drive, and it goes like this:

# disklabel -E sd1
Label editor (enter '?' for help at any prompt)
 > p g
OpenBSD area: 64-1565560769; size: 746.5G; free: 746.5G
#                size           offset  fstype [fsize bsize  cpg]
   c:          2794.5G                0  unused
 > a a
offset: [64]
size: [1565560705]
FS type: [4.2BSD]
Rounding size to bsize (128 sectors): 1565560640
 > p g
OpenBSD area: 64-1565560769; size: 746.5G; free: 0.0G
#                size           offset  fstype [fsize bsize  cpg]
   a:           746.5G               64  4.2BSD   8192 65536    1
   c:          2794.5G                0  unused

Oh.  Hmm.  That doesn't seem to make much sense.  Disklabel is not
letting me create anything larger than ~750GB on what it seems to
realize is a ~2.8GB drive.

That's especially weird, considering I have a 950GB partition on the
1.5TB drive.

At this point I'm wondering WTF is going on.  Is this an
OpenBSD-specific problem?  A BIOS issue?  So I unplug all drives except
one of the 3TB's, install FreeBSD and tell it to use the whole drive.  I
get the exact same results from their disklabel.  Must be the hardware,
right?

Wrong.  Just for laughs I installed Debian Linux, and after a couple of
hours I end up with a usable system.  Not my cup of tea, but hey, I just
want answers at this point.  To my dismay I ended up with 2.7TB of
usable space.  I called it a day and went to bed.

So, with a sense of humour, I come before you today and ask if anyone
can point out the error of my ways.  Surely I'm missing something simple
but important.  Obviously I'd really like to use all available space,
but I'm at a loss.

PS: I forgot to mention, I also tried installing OpenBSD straight from
the 5.1 DVD figuring the installer might know something I don't.  Nope,
same thing.

Thanks for reading this far.


Full dmesg:

OpenBSD 5.1-current (GENERIC.MP) #296: Sun May 20 10:41:35 MDT 2012
[hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12613910528 (12029MB)
avail mem = 12255776768 (11688MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f000 (68 entries)
bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010
bios0: ASUSTeK Computer INC. M4A785TD-V EVO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4)
PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4) PS2K(S4)
UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4)
UHC7(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) II X6 1100T Processor, 3315.24 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu0: AMD erratum 721 detected and fixed
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu1: AMD erratum 721 detected and fixed
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu2: AMD erratum 721 detected and fixed
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu3: AMD erratum 721 detected and fixed
cpu4 at mainbus0: apid 4 (application processor)
cpu4: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
cpu4:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
cpu4: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu4: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu4: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu4: AMD erratum 721 detected and fixed
cpu5 at mainbus0: apid 5 (application processor)
cpu5: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
cpu5:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
cpu5: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
cpu5: ITLB 32 4KB entries fully associative, 16 4MB entries fully
associative
cpu5: DTLB 48 4KB entries fully associative, 48 4MB entries fully
associative
cpu5: AMD erratum 721 detected and fixed
ioapic0 at mainbus0: apid 6 pa 0xfec00000, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus -1 (PCE2)
acpiprt3 at acpi0: bus -1 (PCE3)
acpiprt4 at acpi0: bus -1 (PCE4)
acpiprt5 at acpi0: bus -1 (PCE5)
acpiprt6 at acpi0: bus -1 (PCE6)
acpiprt7 at acpi0: bus -1 (PCE7)
acpiprt8 at acpi0: bus -1 (PCE9)
acpiprt9 at acpi0: bus 2 (PCEA)
acpiprt10 at acpi0: bus 3 (P0PC)
acpicpu0 at acpi0: C2, PSS
acpicpu1 at acpi0: C2, PSS
acpicpu2 at acpi0: C2, PSS
acpicpu3 at acpi0: C2, PSS
acpicpu4 at acpi0: C2, PSS
acpicpu5 at acpi0: C2, PSS
aibs0 at acpi0: RTMP RVLT RFAN GGRP GITM SITM
acpibtn0 at acpi0: PWRB
cpu0: 3315 MHz: speeds: 3300 2500 1700 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD RS880 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 vendor "Asustek", unknown product 0x9602
rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 5 function 0 "ATI Radeon HD 4200" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: apic 6 int 18
drm0 at radeondrm0
azalia0 at pci1 dev 5 function 1 "ATI Radeon HD 4200 HD Audio" rev 0x00: msi
azalia0: no supported codecs
ppb1 at pci0 dev 10 function 0 "AMD RS780 PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D
(0x2800), apic 6 int 18, address 20:cf:30:b0:06:02
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x00: apic 6 int
22, AHCI 1.1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD5000AAKS-0, 05.0> SCSI3
0/direct fixed naa.50014ee001cbd923
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
sd1 at scsibus0 targ 1 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
0/direct fixed naa.5000c5004a6e56f1
sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
sd2 at scsibus0 targ 2 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
0/direct fixed naa.5000c5004a5baa2e
sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 6 int 16,
version 1.0, legacy support
ohci1 at pci0 dev 18 function 1 "ATI SB700 USB" rev 0x00: apic 6 int 16,
version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 6 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "ATI EHCI root hub" rev 2.00/1.00 addr 1
ohci2 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 6 int 18,
version 1.0, legacy support
ohci3 at pci0 dev 19 function 1 "ATI SB700 USB" rev 0x00: apic 6 int 18,
version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 6 int 19
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "ATI EHCI root hub" rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x3c: SMI
iic0 at piixpm0
iic0: addr 0x20 01=19 02=24 03=2e 04=00 05=00 06=00 07=00 08=00 09=00
0a=10 0b=10 0c=10 0d=10 0e=23 0f=92 10=3d 11=00 12=00 13=00 14=0a 15=0a
16=32 17=a0 18=e0 1a=ae 1b=a4 1c=b3 1d=00 1e=0c 1f=01 20=09 21=09 22=09
23=09 24=bb 3e=03 words 00=ff19 01=1924 02=242e 03=2e00 04=0000 05=0000
06=0000 07=0000
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600
spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-10600
spdmem2 at iic0 addr 0x52: 2GB DDR3 SDRAM PC3-10600
spdmem3 at iic0 addr 0x53: 2GB DDR3 SDRAM PC3-10600
pciide0 at pci0 dev 20 function 1 "ATI SB700 IDE" rev 0x00: DMA, channel
0 configured to compatibility, channel 1 configured to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <HL-DT-ST, DVDRAM GSA-4163B, AX13> ATAPI
5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4
azalia1 at pci0 dev 20 function 2 "ATI SBx00 HD Audio" rev 0x00: apic 6
int 16
azalia1: codecs: VIA/0x0397
audio0 at azalia1
pcib0 at pci0 dev 20 function 3 "ATI SB700 ISA" rev 0x00
ppb2 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x00
pci3 at ppb2 bus 3
"D-Link DGE-530T C1" rev 0x10 at pci3 dev 5 function 0 not configured
"VIA VT6306 FireWire" rev 0xc0 at pci3 dev 8 function 0 not configured
ohci4 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 6 int 18,
version 1.0, legacy support
pchb1 at pci0 dev 24 function 0 "AMD AMD64 10h HyperTransport" rev 0x00
pchb2 at pci0 dev 24 function 1 "AMD AMD64 10h Address Map" rev 0x00
pchb3 at pci0 dev 24 function 2 "AMD AMD64 10h DRAM Cfg" rev 0x00
km0 at pci0 dev 24 function 3 "AMD AMD64 10h Misc Cfg" rev 0x00
pchb4 at pci0 dev 24 function 4 "AMD AMD64 10h Link Cfg" rev 0x00
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb4 at ohci2: USB revision 1.0
uhub4 at usb4 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb5 at ohci3: USB revision 1.0
uhub5 at usb5 "ATI OHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
it0 at isa0 port 0x2e/2: IT8712F rev 8, EC port 0x290
usb6 at ohci4: USB revision 1.0
uhub6 at usb6 "ATI OHCI root hub" rev 1.00/1.00 addr 1
mtrr: Pentium Pro MTRR support
uhub7 at uhub0 port 3 "HP\M^? f2105 2PORT USB 2.0 HUB" rev 2.00/7.02 addr 2
uhidev0 at uhub5 port 1 configuration 1 interface 0 "Logitech USB
Receiver" rev 2.00/12.01 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub5 port 1 configuration 1 interface 1 "Logitech USB
Receiver" rev 2.00/12.01 addr 2
uhidev1: iclass 3/1, 8 report ids
ums0 at uhidev1 reportid 2: 16 buttons, Z dir
wsmouse0 at ums0 mux 0
uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
uhidev2 at uhub5 port 1 configuration 1 interface 2 "Logitech USB
Receiver" rev 2.00/12.01 addr 2
uhidev2: iclass 3/0, 33 report ids
uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0
uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0
uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0
uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (6992ea307afaad04.a) swap on sd0b dump on sd0b


--
Scott McEachern

https://www.blackstaff.ca

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Tyler Morgan
On 6/1/2012 10:04 AM, Scott McEachern wrote:
> Hello everyone,
>
> I'm hoping that I'm missing something simple (like usual) and maybe
> someone could straighten me out.
>
> I'm trying to add a pair of 3TB drives to my workstation, which I plan
> on turning into a ~3TB RAID 1 array, and seem to be having difficulty
> realizing the full size of the drives.

http://www.openbsd.org/faq/faq14.html#LargeDrive

I don't have any experience using disks this large in OpenBSD, but ye
olde fine print:

"Note that not all controllers and drivers support large disks. For
example, ami(4) has a limit of 2TB per logical volume. Always be aware
of what was available when a controler or interface was manufactured,
and don't just rely on "the connectors fit"."

However, it's far from hopeless, yet...

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Otto Moerbeek
In reply to this post by Scott McEachern-2
On Fri, Jun 01, 2012 at 01:04:54PM -0400, Scott McEachern wrote:

> Hello everyone,
>
> I'm hoping that I'm missing something simple (like usual) and maybe
> someone could straighten me out.
>
> I'm trying to add a pair of 3TB drives to my workstation, which I
> plan on turning into a ~3TB RAID 1 array, and seem to be having
> difficulty realizing the full size of the drives.
>
> The hardware is about a year old, and less than two years old
> according to the BIOS date:
>
> bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010
> bios0: ASUSTeK Computer INC. M4A785TD-V EVO
>
> (Correction, I've since updated the BIOS to the latest version, just
> in case, and it reads like so:
>
> bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010
>
> and it makes no difference.)
>
> (The full dmesg is below, but for now I'll just post the relevant bits.)
>
> The BIOS happily reports the two drives as present and of 3.0TB
> capacity.  OpenBSD seems to recognize this as well:
>
> sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD5000AAKS-0, 05.0> SCSI3
> 0/direct fixed naa.50014ee001cbd923
> sd0: 476940MB, 512 bytes/sector, 976773168 sectors
> sd1 at scsibus0 targ 1 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> 0/direct fixed naa.5000c5004a6e56f1
> sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
> sd2 at scsibus0 targ 2 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> 0/direct fixed naa.5000c5004a5baa2e
> sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors
>
> (Note that sd0 is my boot/OS drive, and works just fine.  The two
> 3TB drives, sd1 and sd2, will eventually just be used for storage.)
>
> Those numbers look correct, like the OS is properly recognizing the
> capacity.  I have a 1.5TB drive in another machine (a six year-old
> Pentium 4 no less!) that works fine and looks like this:
>
> wd0: 16-sector PIO, LBA48, 1430799MB, 2930277168 sectors
>
> (Although I should mention that that drive has a couple of <1TB
> partitions, so there are no FFS/FFS2 issues.)
>
> I just wanted to get on with my day and not have any fuss, so I
> issued an "fdisk -iy sd1" command on the way to disklabel'ing
> things.  I suspect that's my error, because fdisk says this:  (I've
> added some commas to make for easier reading.)
>
> # fdisk sd1
> Disk: sd1       geometry: 364801/255/63 [1,565,565,872 Sectors]
> Offset: 0       Signature: 0xAA55
>             Starting         Ending         LBA Info:
>  #: id      C   H   S -      C   H   S [       start:        size ]
> -------------------------------------------------------------------------------
>  0: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>  1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>  2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
> *3: A6      0   1   2 -  97451 165  59 [          64:  1,565,560,705
> ] OpenBSD
>
> Uhm, that doesn't seem right, considering the fdisk output for a
> 1.5TB drive looks like this:
>
> # fdisk wd0
> Disk: wd0       geometry: 182401/255/63 [2,930,277,168 Sectors]
> Offset: 0       Signature: 0xAA55
>             Starting         Ending         LBA Info:
>  #: id      C   H   S -      C   H   S [       start:        size ]
> -------------------------------------------------------------------------------
>  0: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>  1: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
>  2: 00      0   0   0 -      0   0   0 [           0:           0 ] unused
> *3: A6      0   1   2 - 182400 254  63 [          64:  2,930,272,001
> ] OpenBSD
>
> A drive with half the capacity seems to have double the numbers, but
> not for geometry.  I suspect that fdisk is lying to me, but I could
> be wrong.
>
> Let's see what disklabel(8) has to say.  On the 1.5TB drive, it
> looks mostly like this (I've snipped some irrelevant partition data
> and added commas to make big numbers easier to read):
>
> # disklabel wd0
> # /dev/rwd0c:
> type: ESDI
> disk: ESDI/IDE disk
> label: ST31500341AS
> duid: dded65e423b05de7
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 182401
> total sectors: 2,930,277,168
> boundstart: 64
> boundend: 2930272065
> drivedata: 0
>
> 16 partitions: (snipped)
> #                size           offset  fstype [fsize bsize  cpg]
>   c:       2,930,277,168                0  unused
>
> On the new 3TB drive, it looks like this:
>
> # disklabel sd1
> # /dev/rsd1c:
> type: SCSI
> disk: SCSI disk
> label: ST3000DM001-9YN1
> duid: 0000000000000000
> flags:
> bytes/sector: 512
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 364801
> total sectors: 5,860,533,168
> boundstart: 64
> boundend: 1565560769
> drivedata: 0
>
> 16 partitions:
> #                size           offset  fstype [fsize bsize  cpg]
>   c:       5,860,533,168                0  unused
>
> Wait a minute here... disklabel seems to have correct data (ignoring
> the duid).  I'll bet I'm failing at grade four math, but that looks
> roughly like a 3TB drive.
>
> So while I'm wondering about going back to grade school, I try
> creating one big partition on the new 3TB drive, and it goes like
> this:
>
> # disklabel -E sd1
> Label editor (enter '?' for help at any prompt)
> > p g
> OpenBSD area: 64-1565560769; size: 746.5G; free: 746.5G
> #                size           offset  fstype [fsize bsize  cpg]
>   c:          2794.5G                0  unused

Do a 'b *' command here, see the man page. That will make the whole
disk available and the a command will do what you expect.

        -Otto

> > a a
> offset: [64]
> size: [1565560705]
> FS type: [4.2BSD]
> Rounding size to bsize (128 sectors): 1565560640
> > p g
> OpenBSD area: 64-1565560769; size: 746.5G; free: 0.0G
> #                size           offset  fstype [fsize bsize  cpg]
>   a:           746.5G               64  4.2BSD   8192 65536    1
>   c:          2794.5G                0  unused
>
> Oh.  Hmm.  That doesn't seem to make much sense.  Disklabel is not
> letting me create anything larger than ~750GB on what it seems to
> realize is a ~2.8GB drive.
>
> That's especially weird, considering I have a 950GB partition on the
> 1.5TB drive.
>
> At this point I'm wondering WTF is going on.  Is this an
> OpenBSD-specific problem?  A BIOS issue?  So I unplug all drives
> except one of the 3TB's, install FreeBSD and tell it to use the
> whole drive.  I get the exact same results from their disklabel.
> Must be the hardware, right?
>
> Wrong.  Just for laughs I installed Debian Linux, and after a couple
> of hours I end up with a usable system.  Not my cup of tea, but hey,
> I just want answers at this point.  To my dismay I ended up with
> 2.7TB of usable space.  I called it a day and went to bed.
>
> So, with a sense of humour, I come before you today and ask if
> anyone can point out the error of my ways.  Surely I'm missing
> something simple but important.  Obviously I'd really like to use
> all available space, but I'm at a loss.
>
> PS: I forgot to mention, I also tried installing OpenBSD straight
> from the 5.1 DVD figuring the installer might know something I
> don't.  Nope, same thing.
>
> Thanks for reading this far.
>
>
> Full dmesg:
>
> OpenBSD 5.1-current (GENERIC.MP) #296: Sun May 20 10:41:35 MDT 2012
> [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 12613910528 (12029MB)
> avail mem = 12255776768 (11688MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f000 (68 entries)
> bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010
> bios0: ASUSTeK Computer INC. M4A785TD-V EVO
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT
> acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4)
> PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4)
> PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4)
> UHC5(S4) UHC6(S4) UHC7(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Phenom(tm) II X6 1100T Processor, 3315.24 MHz
> cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache,
> 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
> cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully
> associative
> cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully
> associative
> cpu0: AMD erratum 721 detected and fixed
> cpu0: apic clock running at 200MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
> cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache,
> 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
> cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully
> associative
> cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully
> associative
> cpu1: AMD erratum 721 detected and fixed
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
> cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
> cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache,
> 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
> cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully
> associative
> cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully
> associative
> cpu2: AMD erratum 721 detected and fixed
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
> cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
> cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache,
> 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
> cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully
> associative
> cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully
> associative
> cpu3: AMD erratum 721 detected and fixed
> cpu4 at mainbus0: apid 4 (application processor)
> cpu4: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
> cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
> cpu4: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache,
> 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
> cpu4: ITLB 32 4KB entries fully associative, 16 4MB entries fully
> associative
> cpu4: DTLB 48 4KB entries fully associative, 48 4MB entries fully
> associative
> cpu4: AMD erratum 721 detected and fixed
> cpu5 at mainbus0: apid 5 (application processor)
> cpu5: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz
> cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT
> cpu5: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache,
> 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache
> cpu5: ITLB 32 4KB entries fully associative, 16 4MB entries fully
> associative
> cpu5: DTLB 48 4KB entries fully associative, 48 4MB entries fully
> associative
> cpu5: AMD erratum 721 detected and fixed
> ioapic0 at mainbus0: apid 6 pa 0xfec00000, version 21, 24 pins
> acpimcfg0 at acpi0 addr 0xe0000000, bus 0-255
> acpihpet0 at acpi0: 14318180 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (P0P1)
> acpiprt2 at acpi0: bus -1 (PCE2)
> acpiprt3 at acpi0: bus -1 (PCE3)
> acpiprt4 at acpi0: bus -1 (PCE4)
> acpiprt5 at acpi0: bus -1 (PCE5)
> acpiprt6 at acpi0: bus -1 (PCE6)
> acpiprt7 at acpi0: bus -1 (PCE7)
> acpiprt8 at acpi0: bus -1 (PCE9)
> acpiprt9 at acpi0: bus 2 (PCEA)
> acpiprt10 at acpi0: bus 3 (P0PC)
> acpicpu0 at acpi0: C2, PSS
> acpicpu1 at acpi0: C2, PSS
> acpicpu2 at acpi0: C2, PSS
> acpicpu3 at acpi0: C2, PSS
> acpicpu4 at acpi0: C2, PSS
> acpicpu5 at acpi0: C2, PSS
> aibs0 at acpi0: RTMP RVLT RFAN GGRP GITM SITM
> acpibtn0 at acpi0: PWRB
> cpu0: 3315 MHz: speeds: 3300 2500 1700 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD RS880 Host" rev 0x00
> ppb0 at pci0 dev 1 function 0 vendor "Asustek", unknown product
> 0x9602 rev 0x00
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 5 function 0 "ATI Radeon HD 4200" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> radeondrm0 at vga1: apic 6 int 18
> drm0 at radeondrm0
> azalia0 at pci1 dev 5 function 1 "ATI Radeon HD 4200 HD Audio" rev 0x00: msi
> azalia0: no supported codecs
> ppb1 at pci0 dev 10 function 0 "AMD RS780 PCIE" rev 0x00: msi
> pci2 at ppb1 bus 2
> re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D
> (0x2800), apic 6 int 18, address 20:cf:30:b0:06:02
> rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
> ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x00: apic 6
> int 22, AHCI 1.1
> scsibus0 at ahci0: 32 targets
> sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD5000AAKS-0, 05.0> SCSI3
> 0/direct fixed naa.50014ee001cbd923
> sd0: 476940MB, 512 bytes/sector, 976773168 sectors
> sd1 at scsibus0 targ 1 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> 0/direct fixed naa.5000c5004a6e56f1
> sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
> sd2 at scsibus0 targ 2 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> 0/direct fixed naa.5000c5004a5baa2e
> sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors
> ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 6 int
> 16, version 1.0, legacy support
> ohci1 at pci0 dev 18 function 1 "ATI SB700 USB" rev 0x00: apic 6 int
> 16, version 1.0, legacy support
> ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 6 int 17
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "ATI EHCI root hub" rev 2.00/1.00 addr 1
> ohci2 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 6 int
> 18, version 1.0, legacy support
> ohci3 at pci0 dev 19 function 1 "ATI SB700 USB" rev 0x00: apic 6 int
> 18, version 1.0, legacy support
> ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 6 int 19
> usb1 at ehci1: USB revision 2.0
> uhub1 at usb1 "ATI EHCI root hub" rev 2.00/1.00 addr 1
> piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x3c: SMI
> iic0 at piixpm0
> iic0: addr 0x20 01=19 02=24 03=2e 04=00 05=00 06=00 07=00 08=00
> 09=00 0a=10 0b=10 0c=10 0d=10 0e=23 0f=92 10=3d 11=00 12=00 13=00
> 14=0a 15=0a 16=32 17=a0 18=e0 1a=ae 1b=a4 1c=b3 1d=00 1e=0c 1f=01
> 20=09 21=09 22=09 23=09 24=bb 3e=03 words 00=ff19 01=1924 02=242e
> 03=2e00 04=0000 05=0000 06=0000 07=0000
> spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600
> spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-10600
> spdmem2 at iic0 addr 0x52: 2GB DDR3 SDRAM PC3-10600
> spdmem3 at iic0 addr 0x53: 2GB DDR3 SDRAM PC3-10600
> pciide0 at pci0 dev 20 function 1 "ATI SB700 IDE" rev 0x00: DMA,
> channel 0 configured to compatibility, channel 1 configured to
> compatibility
> atapiscsi0 at pciide0 channel 0 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0: <HL-DT-ST, DVDRAM GSA-4163B, AX13>
> ATAPI 5/cdrom removable
> cd0(pciide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4
> azalia1 at pci0 dev 20 function 2 "ATI SBx00 HD Audio" rev 0x00:
> apic 6 int 16
> azalia1: codecs: VIA/0x0397
> audio0 at azalia1
> pcib0 at pci0 dev 20 function 3 "ATI SB700 ISA" rev 0x00
> ppb2 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x00
> pci3 at ppb2 bus 3
> "D-Link DGE-530T C1" rev 0x10 at pci3 dev 5 function 0 not configured
> "VIA VT6306 FireWire" rev 0xc0 at pci3 dev 8 function 0 not configured
> ohci4 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 6 int
> 18, version 1.0, legacy support
> pchb1 at pci0 dev 24 function 0 "AMD AMD64 10h HyperTransport" rev 0x00
> pchb2 at pci0 dev 24 function 1 "AMD AMD64 10h Address Map" rev 0x00
> pchb3 at pci0 dev 24 function 2 "AMD AMD64 10h DRAM Cfg" rev 0x00
> km0 at pci0 dev 24 function 3 "AMD AMD64 10h Misc Cfg" rev 0x00
> pchb4 at pci0 dev 24 function 4 "AMD AMD64 10h Link Cfg" rev 0x00
> usb2 at ohci0: USB revision 1.0
> uhub2 at usb2 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb3 at ohci1: USB revision 1.0
> uhub3 at usb3 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb4 at ohci2: USB revision 1.0
> uhub4 at usb4 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb5 at ohci3: USB revision 1.0
> uhub5 at usb5 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> lpt0 at isa0 port 0x378/4 irq 7
> it0 at isa0 port 0x2e/2: IT8712F rev 8, EC port 0x290
> usb6 at ohci4: USB revision 1.0
> uhub6 at usb6 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> mtrr: Pentium Pro MTRR support
> uhub7 at uhub0 port 3 "HP\M^? f2105 2PORT USB 2.0 HUB" rev 2.00/7.02 addr 2
> uhidev0 at uhub5 port 1 configuration 1 interface 0 "Logitech USB
> Receiver" rev 2.00/12.01 addr 2
> uhidev0: iclass 3/1
> ukbd0 at uhidev0: 8 modifier keys, 6 key codes
> wskbd1 at ukbd0 mux 1
> wskbd1: connecting to wsdisplay0
> uhidev1 at uhub5 port 1 configuration 1 interface 1 "Logitech USB
> Receiver" rev 2.00/12.01 addr 2
> uhidev1: iclass 3/1, 8 report ids
> ums0 at uhidev1 reportid 2: 16 buttons, Z dir
> wsmouse0 at ums0 mux 0
> uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0
> uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0
> uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0
> uhidev2 at uhub5 port 1 configuration 1 interface 2 "Logitech USB
> Receiver" rev 2.00/12.01 addr 2
> uhidev2: iclass 3/0, 33 report ids
> uhid3 at uhidev2 reportid 16: input=6, output=6, feature=0
> uhid4 at uhidev2 reportid 17: input=19, output=19, feature=0
> uhid5 at uhidev2 reportid 32: input=14, output=14, feature=0
> uhid6 at uhidev2 reportid 33: input=31, output=31, feature=0
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> root on sd0a (6992ea307afaad04.a) swap on sd0b dump on sd0b
>
>
> --
> Scott McEachern
>
> https://www.blackstaff.ca

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Martin Schröder
In reply to this post by Tyler Morgan
2012/6/1 Tyler Morgan <[hidden email]>:
> http://www.openbsd.org/faq/faq14.html#LargeDrive

That doesn't mention GPT, which is the problem with drives >2TB.
https://en.wikipedia.org/wiki/GUID_Partition_Table

Can OpenBSD already boot from a 4TB drive on an UEFI system?

Best
   Martin

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Nick Holland
In reply to this post by Scott McEachern-2
Otto gave you a good answer here, but I had already provided lots of
detail, so I'm sending anyway. :)

On 06/01/2012 01:04 PM, Scott McEachern wrote:

> Hello everyone,
>
> I'm hoping that I'm missing something simple (like usual) and maybe
> someone could straighten me out.
>
> I'm trying to add a pair of 3TB drives to my workstation, which I plan
> on turning into a ~3TB RAID 1 array, and seem to be having difficulty
> realizing the full size of the drives.
>
> The hardware is about a year old, and less than two years old according
> to the BIOS date:
>
> bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010
> bios0: ASUSTeK Computer INC. M4A785TD-V EVO
>
> (Correction, I've since updated the BIOS to the latest version, just in
> case, and it reads like so:
>
> bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010
>
> and it makes no difference.)
>
> (The full dmesg is below, but for now I'll just post the relevant bits.)
>
> The BIOS happily reports the two drives as present and of 3.0TB
> capacity. OpenBSD seems to recognize this as well:
>
> sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD5000AAKS-0, 05.0> SCSI3
> 0/direct fixed naa.50014ee001cbd923
> sd0: 476940MB, 512 bytes/sector, 976773168 sectors
> sd1 at scsibus0 targ 1 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> 0/direct fixed naa.5000c5004a6e56f1
> sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
> sd2 at scsibus0 targ 2 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> 0/direct fixed naa.5000c5004a5baa2e
> sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors

Life is good.

...

> I just wanted to get on with my day and not have any fuss, so I issued
> an "fdisk -iy sd1" command on the way to disklabel'ing things. I suspect
> that's my error, because fdisk says this: (I've added some commas to
> make for easier reading.)
>
> # fdisk sd1
> Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
> -------------------------------------------------------------------------------
>
> 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD
>
> Uhm, that doesn't seem right

well. it's annoying, but "rightish". :)
fdisk edits MBRs, MBR has a limit of 2TB on its structures.
So...it looks like fdisk basically did a 3TB modulo 2TB.  I really
should save myself looking like a fool and check my math, but if I'm
wrong, it will teach you not to take what I say as gospel :)

Some OSs want you to switch to a new way of handling big disks, but I do
think OpenBSD will do what you want "natively".

..
> A drive with half the capacity seems to have double the numbers, but not
> for geometry. I suspect that fdisk is lying to me, but I could be wrong.

you are right.

> Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks
> mostly like this (I've snipped some irrelevant partition data and added
> commas to make big numbers easier to read):
..

> total sectors: 2,930,277,168
> boundstart: 64
> boundend: 2930272065
> drivedata: 0
>
> 16 partitions: (snipped)
> # size offset fstype [fsize bsize cpg]
> c: 2,930,277,168 0 unused
>
> On the new 3TB drive, it looks like this:
>
> # disklabel sd1
..

> total sectors: 5,860,533,168
> boundstart: 64
> boundend: 1565560769
> drivedata: 0
>
> 16 partitions:
> # size offset fstype [fsize bsize cpg]
> c: 5,860,533,168 0 unused
>
> Wait a minute here... disklabel seems to have correct data (ignoring the
> duid). I'll bet I'm failing at grade four math, but that looks roughly
> like a 3TB drive.

yes, it's a 3TB disk, but at the moment, disklabel is restricting you to
just the fdisk-marked part of the drive...which is as it should be.  You
generally don't want your OpenBSD partitions living outside the OpenBSD
MBR (fdisk) partition.
   EXCEPT when the MBR isn't providing useful info.  Like now.

...
> At this point I'm wondering WTF is going on. Is this an OpenBSD-specific
> problem? A BIOS issue? So I unplug all drives except one of the 3TB's,
> install FreeBSD and tell it to use the whole drive. I get the exact same
> results from their disklabel. Must be the hardware, right?

What you want to do is use the 'b' option of disklabel to redefine the
OpenBSD boundaries of the disk.  I do believe it will let you specify
the whole disk, and you can then do what you want.

A few words of warning...

* This really messes up your ability to multiboot, as non-OpenBSD OSs
will think anything beyond the fdisk/MBR partition might be available.
But then, most other OSs choke pretty badly at this point anyway.  may
not be that big a problem.
* Lots of BIOSes that see >128G disks still won't let you boot from
partitions higher than 128G.
* I haven't actually TRIED this.  I was planning on buying a 3TB disk to
experiment on and update FAQ14...but just before I did, there was this
little flood issue, and being a cheapskate, I didn't want to sink a lot
of money into a drive I didn't really need quite yet (or more
accurately, I need TWO of...)
* Rebuilding the mirror will be a beast.
* you don't want to fsck a 3TB file system, 'specially if it is
rebuilding the mirror at the same time, though with 12G RAM, you might
be able to do it.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Otto Moerbeek
In reply to this post by Martin Schröder
On Fri, Jun 01, 2012 at 09:26:41PM +0200, Martin Schr?der wrote:

> 2012/6/1 Tyler Morgan <[hidden email]>:
> > http://www.openbsd.org/faq/faq14.html#LargeDrive
>
> That doesn't mention GPT, which is the problem with drives >2TB.
> https://en.wikipedia.org/wiki/GUID_Partition_Table
>
> Can OpenBSD already boot from a 4TB drive on an UEFI system?
>
> Best
>    Martin


OpenBSD handles >2TB disks fine. A problem is that fdisk cannot
correctly partiton such large disks, but disklabel is happy to ignore
that fact using the b command.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Theo de Raadt
In reply to this post by Martin Schröder
> 2012/6/1 Tyler Morgan <[hidden email]>:
> > http://www.openbsd.org/faq/faq14.html#LargeDrive
>
> That doesn't mention GPT, which is the problem with drives >2TB.
> https://en.wikipedia.org/wiki/GUID_Partition_Table
>
> Can OpenBSD already boot from a 4TB drive on an UEFI system?

Try to buy systems that don't rely on UEFI.  In the next few years,
prepare to buy systems and find out they require UEFI, and then demand
a refund.  Prepare for it to get even worse than that.

If you buy a UEFI-capable system today, you are giving power to the
people who will (in the future) make UEFI-only systems which are
incapable of running OpenBSD.

UEFI arrived with all sorts of promises of making machines better, but
is being turned into something completely nefarious.

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Nick Holland
In reply to this post by Martin Schröder
On 06/01/2012 03:26 PM, Martin Schrvder wrote:

> 2012/6/1 Tyler Morgan<[hidden email]>:
>> http://www.openbsd.org/faq/faq14.html#LargeDrive
>
> That doesn't mention GPT, which is the problem with drives>2TB.
> https://en.wikipedia.org/wiki/GUID_Partition_Table
>
> Can OpenBSD already boot from a 4TB drive on an UEFI system?
>
> Best
>     Martin

OpenBSD doesn't support booting from UEFI/GPT stuff at this point, but
it is as needed as being able to boot from the tail of a 1TB disk when
your bios only supports the first 32G.  or 504M.  or 128G.  or whatever
limit your BIOS has.  It isn't needed.  Hint: a lot of machines
purchased today still have problems BOOTING beyond 128G, even though the
BIOS reports the entire disk (and this is clearly a BIOS problem, I have
several machines which DO boot fine beyond 128G), and you can use 2TB
disks on those systems Just Fine.

OpenBSD needs to load the boot loader from something the BIOS recognizes
(an MBR/fdisk partition).  From there, the OS has to be able to figure
out where the rest of the disk is (disklabel).

Look Ma, no UEFI!

Now, if you want to multiboot four different OSs, and put OpenBSD as the
last 500GB of a 3TB disk, not so pretty.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Christian Weisgerber
In reply to this post by Scott McEachern-2
Scott McEachern <[hidden email]> wrote:

> I'm trying to add a pair of 3TB drives to my workstation, which I plan
> on turning into a ~3TB RAID 1 array, and seem to be having difficulty
> realizing the full size of the drives.

The partition table in the MBR is limited to 32-bit numbers.
512 bytes/sector * 2^32 sectors = 2 TB

In practice, fdisk -i will create an OpenBSD MBR partition of a
size modulo 2 TB.  If you don't share the disk with other operating
systems, this doesn't matter.

In disklabel, use the 'b' command to set the upper end of the OpenBSD
disk boundary to the entire size of the disk.  You can then make
full use of the drive when creating partitions.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

gwes-2
In reply to this post by Theo de Raadt
On 06/01/2012 03:41 PM, Theo de Raadt wrote:

>> 2012/6/1 Tyler Morgan<[hidden email]>:
>>> http://www.openbsd.org/faq/faq14.html#LargeDrive
>> That doesn't mention GPT, which is the problem with drives>2TB.
>> https://en.wikipedia.org/wiki/GUID_Partition_Table
>>
>> Can OpenBSD already boot from a 4TB drive on an UEFI system?
> Try to buy systems that don't rely on UEFI.  In the next few years,
> prepare to buy systems and find out they require UEFI, and then demand
> a refund.  Prepare for it to get even worse than that.
>
> If you buy a UEFI-capable system today, you are giving power to the
> people who will (in the future) make UEFI-only systems which are
> incapable of running OpenBSD.
>
> UEFI arrived with all sorts of promises of making machines better, but
> is being turned into something completely nefarious.
On the surface, UEFI seems to allow the manufacturer and others to
insert any amount of black-box malware during boot. That's enough
to make me shudder. Obviously, opportunities abound for that code
to prevent "unauthorized" O/Ses from running or subvert them once
running.

Are there other and larger issues?

On the other hand, GPT by itself appears useful. Does it also
contain boobytraps?

Thanks!
Geoff Steckel

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Theo de Raadt
> On the other hand, GPT by itself appears useful.

What is useful about GPT?  *EVERY USER* has the following
simple requirements:

    1. I have a machine.
    2. I want to install an operating system on it (or, have an
       operating system installed from the factory)

What am I missing -- what is useful about GPT?

I guess I mean -- what is *MORE* useful about GPT, compared to the
other options already available?

I guess I should be even more clear:  Does GPT provide any
functionality that *EVERY USER* needs?

No, it does not.

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

gwes-2
On 06/01/2012 04:55 PM, Theo de Raadt wrote:

>> On the other hand, GPT by itself appears useful.
> What is useful about GPT?  *EVERY USER* has the following
> simple requirements:
>
>      1. I have a machine.
>      2. I want to install an operating system on it (or, have an
>         operating system installed from the factory)
>
> What am I missing -- what is useful about GPT?
>
> I guess I mean -- what is *MORE* useful about GPT, compared to the
> other options already available?
>
> I guess I should be even more clear:  Does GPT provide any
> functionality that *EVERY USER* needs?
>
> No, it does not.
I agree completely that any OS can write any kind of disk label
(or none) that it needs. As you say, in the very, very large
majority of cases no FDISK or GPT or anything else external
to the loaded OS is needed.

The apparent advantage of GPT over FDISK partitions is that it
can describe partitions > 2TB for systems hosting multiple
OSes. That's all I meant. Sorry that it wasn't clear.

Geoff Steckel

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Theo de Raadt
> The apparent advantage of GPT over FDISK partitions is that it
> can describe partitions > 2TB for systems hosting multiple
> OSes. That's all I meant. Sorry that it wasn't clear.

US-based missile-armed predator drones by themselves appear useful.

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Eric Furman-3
In reply to this post by Nick Holland
On Fri, Jun 1, 2012, at 03:27 PM, Nick Holland wrote:

> Otto gave you a good answer here, but I had already provided lots of
> detail, so I'm sending anyway. :)
>
> On 06/01/2012 01:04 PM, Scott McEachern wrote:
> > Hello everyone,
> >
> > I'm hoping that I'm missing something simple (like usual) and maybe
> > someone could straighten me out.
> >
> > I'm trying to add a pair of 3TB drives to my workstation, which I plan
> > on turning into a ~3TB RAID 1 array, and seem to be having difficulty
> > realizing the full size of the drives.
> >
> > The hardware is about a year old, and less than two years old according
> > to the BIOS date:
> >
> > bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010
> > bios0: ASUSTeK Computer INC. M4A785TD-V EVO
> >
> > (Correction, I've since updated the BIOS to the latest version, just in
> > case, and it reads like so:
> >
> > bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010
> >
> > and it makes no difference.)
> >
> > (The full dmesg is below, but for now I'll just post the relevant bits.)
> >
> > The BIOS happily reports the two drives as present and of 3.0TB
> > capacity. OpenBSD seems to recognize this as well:
> >
> > sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD5000AAKS-0, 05.0> SCSI3
> > 0/direct fixed naa.50014ee001cbd923
> > sd0: 476940MB, 512 bytes/sector, 976773168 sectors
> > sd1 at scsibus0 targ 1 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> > 0/direct fixed naa.5000c5004a6e56f1
> > sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
> > sd2 at scsibus0 targ 2 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> > 0/direct fixed naa.5000c5004a5baa2e
> > sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors
>
> Life is good.
>
> ...
>
> > I just wanted to get on with my day and not have any fuss, so I issued
> > an "fdisk -iy sd1" command on the way to disklabel'ing things. I suspect
> > that's my error, because fdisk says this: (I've added some commas to
> > make for easier reading.)
> >
> > # fdisk sd1
> > Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors]
> > Offset: 0 Signature: 0xAA55
> > Starting Ending LBA Info:
> > #: id C H S - C H S [ start: size ]
> > -------------------------------------------------------------------------------
> >
> > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> > *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD
> >
> > Uhm, that doesn't seem right
>
> well. it's annoying, but "rightish". :)
> fdisk edits MBRs, MBR has a limit of 2TB on its structures.
> So...it looks like fdisk basically did a 3TB modulo 2TB.  I really
> should save myself looking like a fool and check my math, but if I'm
> wrong, it will teach you not to take what I say as gospel :)
>
> Some OSs want you to switch to a new way of handling big disks, but I do
> think OpenBSD will do what you want "natively".
>
> ..
> > A drive with half the capacity seems to have double the numbers, but not
> > for geometry. I suspect that fdisk is lying to me, but I could be wrong.
>
> you are right.
>
> > Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks
> > mostly like this (I've snipped some irrelevant partition data and added
> > commas to make big numbers easier to read):
> ..
> > total sectors: 2,930,277,168
> > boundstart: 64
> > boundend: 2930272065
> > drivedata: 0
> >
> > 16 partitions: (snipped)
> > # size offset fstype [fsize bsize cpg]
> > c: 2,930,277,168 0 unused
> >
> > On the new 3TB drive, it looks like this:
> >
> > # disklabel sd1
> ..
> > total sectors: 5,860,533,168
> > boundstart: 64
> > boundend: 1565560769
> > drivedata: 0
> >
> > 16 partitions:
> > # size offset fstype [fsize bsize cpg]
> > c: 5,860,533,168 0 unused
> >
> > Wait a minute here... disklabel seems to have correct data (ignoring the
> > duid). I'll bet I'm failing at grade four math, but that looks roughly
> > like a 3TB drive.
>
> yes, it's a 3TB disk, but at the moment, disklabel is restricting you to
> just the fdisk-marked part of the drive...which is as it should be.  You
> generally don't want your OpenBSD partitions living outside the OpenBSD
> MBR (fdisk) partition.
>    EXCEPT when the MBR isn't providing useful info.  Like now.
>
> ...
> > At this point I'm wondering WTF is going on. Is this an OpenBSD-specific
> > problem? A BIOS issue? So I unplug all drives except one of the 3TB's,
> > install FreeBSD and tell it to use the whole drive. I get the exact same
> > results from their disklabel. Must be the hardware, right?
>
> What you want to do is use the 'b' option of disklabel to redefine the
> OpenBSD boundaries of the disk.  I do believe it will let you specify
> the whole disk, and you can then do what you want.
>
> A few words of warning...
>
> * This really messes up your ability to multiboot, as non-OpenBSD OSs
> will think anything beyond the fdisk/MBR partition might be available.
> But then, most other OSs choke pretty badly at this point anyway.  may
> not be that big a problem.
> * Lots of BIOSes that see >128G disks still won't let you boot from
> partitions higher than 128G.
> * I haven't actually TRIED this.  I was planning on buying a 3TB disk to
> experiment on and update FAQ14...but just before I did, there was this
> little flood issue, and being a cheapskate, I didn't want to sink a lot
> of money into a drive I didn't really need quite yet (or more
> accurately, I need TWO of...)
> * Rebuilding the mirror will be a beast.
> * you don't want to fsck a 3TB file system, 'specially if it is
> rebuilding the mirror at the same time, though with 12G RAM, you might
> be able to do it.
>
> Nick.
>

Looks like Nick and OBSD could use a Donation.
Anyone here in the community willing to step up
and donate a couple 3TB drives?
I would if I could so I understand if some people can't,
but I'm sure there are a few people out there.

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Chris Cappuccio
In reply to this post by Nick Holland
Nick Holland [[hidden email]] wrote:
> * you don't want to fsck a 3TB file system, 'specially if it is
> rebuilding the mirror at the same time, though with 12G RAM, you
> might be able to do it.
>

Isn't this situation seriously improved with fsck in 5.1 ?

Reply | Threaded
Open this post in threaded view
|

Re: [OBSD Misc] Re: Large (3TB) HDD support

Jason Bergstrom
In reply to this post by Eric Furman-3
> On Fri, Jun 1, 2012, at 03:27 PM, Nick Holland wrote:
> > Otto gave you a good answer here, but I had already provided lots of
> > detail, so I'm sending anyway. :)
> >
> > On 06/01/2012 01:04 PM, Scott McEachern wrote:
> > > Hello everyone,
> > >
> > > I'm hoping that I'm missing something simple (like usual) and maybe
> > > someone could straighten me out.
> > >
> > > I'm trying to add a pair of 3TB drives to my workstation, which I plan
> > > on turning into a ~3TB RAID 1 array, and seem to be having difficulty
> > > realizing the full size of the drives.
> > >
> > > The hardware is about a year old, and less than two years old according
> > > to the BIOS date:
> > >
> > > bios0: vendor American Megatrends Inc. version "2103" date 06/18/2010
> > > bios0: ASUSTeK Computer INC. M4A785TD-V EVO
> > >
> > > (Correction, I've since updated the BIOS to the latest version, just in
> > > case, and it reads like so:
> > >
> > > bios0: vendor American Megatrends Inc. version "2105" date 07/23/2010
> > >
> > > and it makes no difference.)
> > >
> > > (The full dmesg is below, but for now I'll just post the relevant bits.)
> > >
> > > The BIOS happily reports the two drives as present and of 3.0TB
> > > capacity. OpenBSD seems to recognize this as well:
> > >
> > > sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD5000AAKS-0, 05.0> SCSI3
> > > 0/direct fixed naa.50014ee001cbd923
> > > sd0: 476940MB, 512 bytes/sector, 976773168 sectors
> > > sd1 at scsibus0 targ 1 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> > > 0/direct fixed naa.5000c5004a6e56f1
> > > sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
> > > sd2 at scsibus0 targ 2 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
> > > 0/direct fixed naa.5000c5004a5baa2e
> > > sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors
> >
> > Life is good.
> >
> > ...
> >
> > > I just wanted to get on with my day and not have any fuss, so I issued
> > > an "fdisk -iy sd1" command on the way to disklabel'ing things. I suspect
> > > that's my error, because fdisk says this: (I've added some commas to
> > > make for easier reading.)
> > >
> > > # fdisk sd1
> > > Disk: sd1 geometry: 364801/255/63 [1,565,565,872 Sectors]
> > > Offset: 0 Signature: 0xAA55
> > > Starting Ending LBA Info:
> > > #: id C H S - C H S [ start: size ]
> > > -------------------------------------------------------------------------------
> > >
> > > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> > > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> > > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> > > *3: A6 0 1 2 - 97451 165 59 [ 64: 1,565,560,705 ] OpenBSD
> > >
> > > Uhm, that doesn't seem right
> >
> > well. it's annoying, but "rightish". :)
> > fdisk edits MBRs, MBR has a limit of 2TB on its structures.
> > So...it looks like fdisk basically did a 3TB modulo 2TB.  I really
> > should save myself looking like a fool and check my math, but if I'm
> > wrong, it will teach you not to take what I say as gospel :)
> >
> > Some OSs want you to switch to a new way of handling big disks, but I do
> > think OpenBSD will do what you want "natively".
> >
> > ..
> > > A drive with half the capacity seems to have double the numbers, but not
> > > for geometry. I suspect that fdisk is lying to me, but I could be wrong.
> >
> > you are right.
> >
> > > Let's see what disklabel(8) has to say. On the 1.5TB drive, it looks
> > > mostly like this (I've snipped some irrelevant partition data and added
> > > commas to make big numbers easier to read):
> > ..
> > > total sectors: 2,930,277,168
> > > boundstart: 64
> > > boundend: 2930272065
> > > drivedata: 0
> > >
> > > 16 partitions: (snipped)
> > > # size offset fstype [fsize bsize cpg]
> > > c: 2,930,277,168 0 unused
> > >
> > > On the new 3TB drive, it looks like this:
> > >
> > > # disklabel sd1
> > ..
> > > total sectors: 5,860,533,168
> > > boundstart: 64
> > > boundend: 1565560769
> > > drivedata: 0
> > >
> > > 16 partitions:
> > > # size offset fstype [fsize bsize cpg]
> > > c: 5,860,533,168 0 unused
> > >
> > > Wait a minute here... disklabel seems to have correct data (ignoring the
> > > duid). I'll bet I'm failing at grade four math, but that looks roughly
> > > like a 3TB drive.
> >
> > yes, it's a 3TB disk, but at the moment, disklabel is restricting you to
> > just the fdisk-marked part of the drive...which is as it should be.  You
> > generally don't want your OpenBSD partitions living outside the OpenBSD
> > MBR (fdisk) partition.
> >    EXCEPT when the MBR isn't providing useful info.  Like now.
> >
> > ...
> > > At this point I'm wondering WTF is going on. Is this an OpenBSD-specific
> > > problem? A BIOS issue? So I unplug all drives except one of the 3TB's,
> > > install FreeBSD and tell it to use the whole drive. I get the exact same
> > > results from their disklabel. Must be the hardware, right?
> >
> > What you want to do is use the 'b' option of disklabel to redefine the
> > OpenBSD boundaries of the disk.  I do believe it will let you specify
> > the whole disk, and you can then do what you want.
> >
> > A few words of warning...
> >
> > * This really messes up your ability to multiboot, as non-OpenBSD OSs
> > will think anything beyond the fdisk/MBR partition might be available.
> > But then, most other OSs choke pretty badly at this point anyway.  may
> > not be that big a problem.
> > * Lots of BIOSes that see >128G disks still won't let you boot from
> > partitions higher than 128G.
> > * I haven't actually TRIED this.  I was planning on buying a 3TB disk to
> > experiment on and update FAQ14...but just before I did, there was this
> > little flood issue, and being a cheapskate, I didn't want to sink a lot
> > of money into a drive I didn't really need quite yet (or more
> > accurately, I need TWO of...)
> > * Rebuilding the mirror will be a beast.
> > * you don't want to fsck a 3TB file system, 'specially if it is
> > rebuilding the mirror at the same time, though with 12G RAM, you might
> > be able to do it.
> >
> > Nick.
> >
>
> Looks like Nick and OBSD could use a Donation.
> Anyone here in the community willing to step up
> and donate a couple 3TB drives?
> I would if I could so I understand if some people can't,
> but I'm sure there are a few people out there.
>

I have two older Western Digital WD30EZRSDTL drives I can part with.

Jason,
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

David Diggles-2
In reply to this post by Chris Cappuccio
On Fri, Jun 01, 2012 at 04:32:19PM -0700, Chris Cappuccio wrote:
> Nick Holland [[hidden email]] wrote:
> > * you don't want to fsck a 3TB file system, 'specially if it is
> > rebuilding the mirror at the same time, though with 12G RAM, you
> > might be able to do it.
> >
>
> Isn't this situation seriously improved with fsck in 5.1 ?
>

I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1...
it took a while, but worked.

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Stuart Henderson
In reply to this post by Chris Cappuccio
On 2012-06-01, Chris Cappuccio <[hidden email]> wrote:
> Nick Holland [[hidden email]] wrote:
>> * you don't want to fsck a 3TB file system, 'specially if it is
>> rebuilding the mirror at the same time, though with 12G RAM, you
>> might be able to do it.
>>
>
> Isn't this situation seriously improved with fsck in 5.1 ?

Quite a lot. But you might still want to bump -i when you newfs (unless
you actually need all those inodes). Default is based on the frag size,
but there's a limit to frag size, so it stops scaling back the inode
count after a point, and lots of inodes can really slow down fsck.

If the majority of your files are "media" you might want to increase
it a bit, if you're keeping large backups you might want to increase
it a lot. From a bacula box...

$ df -hi /bak
Filesystem     Size    Used   Avail Capacity iused   ifree  %iused  Mounted on
/dev/sd2m      2.7T    1.4T    1.2T    56%     146  175212     0%   /bak

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Christian Weisgerber
In reply to this post by David Diggles-2
David Diggles <[hidden email]> wrote:

> I fsck'd two 3TB filesystems yesterday with 512MB ram, on 5.1...
> it took a while, but worked.

I just fsck'ed a 2.7TB filesystem in 1 minute, 43 seconds.
61% full, 447166 files.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Large (3TB) HDD support

Scott McEachern-2
In reply to this post by Otto Moerbeek
On 06/01/12 15:13, Otto Moerbeek wrote:
> Do a 'b *' command here, see the man page. That will make the whole
> disk available and the a command will do what you expect. -Otto

Thank-you Otto and others for your assistance, that did the trick!

I got both drives online, and set them up as a RAID 1 volume.  A little
geek porn if I may (I've never seen anything quite like that before.  
Ha!  Until sthen@ posted his message):

# df -h /st4
Filesystem                                              Size    Used  
Avail Capacity  Mounted on
/dev/sd3a                                               2.7T    8.0K    
2.6T     0%    /st4

Some snipped dmesg:

sd3 at scsibus3 targ 1 lun 0: <OPENBSD, SR RAID 1, 005> SCSI2 0/direct fixed
sd3: 2861588MB, 512 bytes/sector, 5860532640 sectors

Now I can lighten the load on some of my other drives. :)

On 06/01/12 15:27, Nick Holland wrote:

>> 0/direct fixed naa.50014ee001cbd923
>> sd0: 476940MB, 512 bytes/sector, 976773168 sectors
>> sd1 at scsibus0 targ 1 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
>> 0/direct fixed naa.5000c5004a6e56f1
>> sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors
>> sd2 at scsibus0 targ 2 lun 0: <ATA, ST3000DM001-9YN1, CC4B> SCSI3
>> 0/direct fixed naa.5000c5004a5baa2e
>> sd2: 2861588MB, 512 bytes/sector, 5860533168 sectors
>
>
> Life is good.
>

Oh, indeed!  However, it'll take me at least a week to xfer my DVD stuff
onto it...

>
> A few words of warning...
>
> * This really messes up your ability to multiboot, as non-OpenBSD OSs
> will think anything beyond the fdisk/MBR partition might be available.
> But then, most other OSs choke pretty badly at this point anyway.  may
> not be that big a problem.

I won't be multibooting this box any more.  (It was once a triple boot
WinXP/Win7/OpenBSD machine.)  These days, I just buy really cheap used
PCs for my occasional Windows needs.  Life is easier with cheap hardware
than bothering with multiple OSes on one box.


> * Lots of BIOSes that see >128G disks still won't let you boot from
> partitions higher than 128G.
> * I haven't actually TRIED this.  I was planning on buying a 3TB disk
> to experiment on and update FAQ14...but just before I did, there was
> this little flood issue, and being a cheapskate, I didn't want to sink
> a lot of money into a drive I didn't really need quite yet (or more
> accurately, I need TWO of...)

I was in the exact same boat; I'm a cheapskate too.  I watched the same
model drive double in price (about $180 CDN to about $400) overnight,
and eventually they went down to $170.  I kept scratching my chin on the
idea, and the last straw was when (yet again) if I wanted a file
(typically a movie), I'd have to dig up the DVD.  I literally have
hundreds of DVDs.  It's seriously inconvenient to buy blanks, burn the
data, hope it hasn't degraded when you need it, load it back...  I
figured "Screw it", take the plunge.  I think you know what I'd
recommend... :)

> * Rebuilding the mirror will be a beast.
> * you don't want to fsck a 3TB file system, 'specially if it is
> rebuilding the mirror at the same time, though with 12G RAM, you might
> be able to do it.
>
> Nick.
>

I'm hoping luck will stay on my side and I don't have to rebuild any
time soon.  And if things go sideways, which I always assume, I have
other workstations I can use (that one just happens to be the 'best').  
Good eye on noticing the 12GB of RAM; I'm sure that will come in handy
when things go wrong.  I'll be ordering a third 3TB drive as a spare,
but in a while.  I don't want them all to be from the same batch.

I have a web server (Pentium 4) with two 40GB drives in RAID 1 as well,
plus a spare in storage.  (Not a typo, 40GB.)  As you've written before,
don't trust it, test it, so I pulled a drive, threw in my spare and let
it rebuild.  I believe that took half a day.  I'm sure 3TB will be very,
very ugly even on a machine considerably faster than a P4.

BTW, I'm nicely UPSed and have pretty reliable hydro where I live, but
stuff happens.  That Pentium 4 with the 1.5TB drive only has 1GB of RAM,
but I've been pleasantly surprised on the couple of times it's had to
fsck the drive.  I believe it only took about 10 minutes for it to sort
things out the last time, but it's pretty much read-only.


So thanks again folks for the advice!

--
Scott McEachern

https://www.blackstaff.ca

123