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.
