What's so special about /dev/vn0a?

[David Wolfskill]

Seems that I can't refer - explicitly -- to partition "a" of a
partitioned "vnode disk" if it's assigned /dev/vn0.  If I assign it
/dev/vn1, no problem.  If I change the name of the partition to "b", no
problem.  I can even just refer to it as /dev/vn0, and /dev/vn0a gets
selected.

So I'm a tad puzzled.  This isn't the End Of The World As We Know It,
but the apparent lack of consistency is ... curious, at least.

I'm running 4.9-R, recompiled mostly to get "device vn" in the kernel:

%uname -a
FreeBSD frecnocpc10.noc.egation.com 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Thu Nov 13 13:17:27 PST 2003     root at frecnocpc10.noc.egation.com:/usr/src/sys/compile/MADCASTER  i386
%sudo vnconfig -s labels -c vn0 vn_jail
%sudo disklabel -r vn0 | tail
Password:
track-to-track seek: 0  # milliseconds
drivedata: 0 

8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:    16000        0    4.2BSD     2048 16384   107   # (Cyl.    0 - 7*)
  c:  2662400        0    unused        0     0         # (Cyl.    0 - 1299)
  e:    16000    16000    4.2BSD     2048 16384   107   # (Cyl.    7*- 15*)
  g:      400    32000    4.2BSD     2048 16384   107   # (Cyl.   15*- 15*)
  h:  2630000    32400    4.2BSD     2048 16384    90   # (Cyl.   15*- 1299*)
%sudo df /dev/vn0
Filesystem                             1K-blocks      Used    Avail Capacity  Mounted on
/dev/vn0                                    7822      6572      626    91%    
%sudo df /dev/vn0a
df: /dev/vn0a: Device not configured
%sudo vnconfig -u vn0
%sudo vnconfig -s labels -c vn1 vn_jail
%sudo df /dev/vn1
Filesystem                             1K-blocks      Used    Avail Capacity  Mounted on
/dev/vn1                                    7822      6572      626    91%    
%sudo df /dev/vn1a
Filesystem                             1K-blocks      Used    Avail Capacity  Mounted on
/dev/vn1a                                   7822      6572      626    91%    
%sudo vnconfig -u vn1
%

I admit that I've done but the most cursory of reality checks, but come
up empty-handed.  Is this intentional?

I'm certainly willing to submit a PR if it's broken;  indeed, I'm
willing to go poke around in the code and try to understand where
things are going wrong -- but I'd rather avoid that exercise if this
really is working as designed.

Thanks,
david
-- 
David H. Wolfskill                                 david at egation.com