Re: partitioning >2TB?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

Okay, I have more information.

----------------

First, the crash.  I booted with the raidframe disks in place (so raid0
exists this time).  Then:

# dkctl raid0 addwedge dumps 128 1565607168 4.2BSD

This says it works, and it appears to; dkctl raid0 listwedges shows

/dev/rraid0d: 1 wedge:
dk0: dumps, 1565607168 blocks at 128, type: 4.2BSD

I have a program probepartsize, which figures out a partition's size by
doing binary search, reading single blocks at assorted offsets to see
which ones work.  When I sic that on my manually-created /dev/rdk0a
(character special 168 0, this based on /usr/src/sys/conf/majors), I
get an instant panic.  Here's a ten-finger copy:

uvm_fault(0xcc59c384, 0, 1) -> 0xe
kernel: supervisor trap page fault, code = 0
Stopped in pid 2495.1 (probepartsize) at netbsd:dkread+0x39: movl 0x4(%eax), 
%eax

A ddb stack trace shows dkread+0x39, spec_read+0x214, VOP_READ+0x31,
vn_read+0xae, dofileread+0xc6, sys_read+0x7f, syscall_plain+0x149.
Looking at the source to dkread() and comparing it to disassembly, it
appears dkwedge_lookup returned a real pointer, but one of the
pointer-follows involved in sc->sc_parent->dk_driver->d_minphys failed.
I have a kernel coredump in case there's something useful that can be
done with it.

Comparing dkopen and dkread between 4.0 and current, I don't see
anything that would explain this working in current but not 4.0.

----------------

Second, the problem with gpt(8).  THe message is being misleading.
ktrace reveals that it's opening /dev/rraid0d just fine; what's failing
is opening /dev/drvctl, and the problem here is that the message
printed (incorrectly) implies that it's rraid0d that it couldn't open.
(There's also the question of _why_ it couldn't open /dev/drvctl, but
that's a separate problem; vide infra.)

/dev/drvctl is character special 167 0, which looks correct based on
/usr/src/etc/MAKEDEV.tmpl and /usr/src/sys/conf/majors - so, while
/dev/ may be a 3.x remnant, and while drvctl looks like what
/dev/MAKEDEV would create, it appears to match the 4.0 kernel in use.

For the moment, I'm just using newfs -I -F on /dev/rraid0d with a -s
value obtained from raidframe, avoiding the gpt and wedge issues.

----------------

In passing, every first-open on raid0, I get a kernel message

raid0: WARNING: raid0: total sector size in disklabel (1565607296) != the size 
of raid (1565607296)

which looks totally bizarre, complaining that two obviously equal
numbers are unequal.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B