Re: 1.9.x slices, newfs, and vinum problem?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:unfortunately, more strangeness -
:
:good bits of disklabel -r /dev/ad1s1:
:
:  a:   78156225          0     vinum    #   38162.219M
:  c:   78156225          0    unused    #   38162.219M
:
:- vinum create for the drives as follows:
:
:  drive d1 device /dev/ad1s1a
:  drive d2 device /dev/ad3s1a
:
:  fails with the drives being in 'down' state, dmesg reports:
:
:  vinum: Can't write config to /dev/ad1s1a, error 30
:  vinum: Can't write config to /dev/ad3s1a, error 30
:
:  (errno.h: #define EROFS 30 /* Read-only file system */)
:
:- newfs /dev/ad1s1a with either vinum or 4.2BSD 'fstype' OK
:- mount /dev/ad1s1a with 4.2BSD fstype OK
:- ccd as "ccd0 128 none /dev/ad1s1a /dev/ad3s1a"
:  labels, formats, mounts OK
:- dd if=/dev/zero of=/dev/ad1s1a reports
:  dd: /dev/ad1s1a: Read-only file system
:- dd if=/dev/zero of=/dev/ad1s1 is fine
:  (but blows out the label, as expeced)
:
:when this machine was upgraded to 1.9 a few weeks back,
:I made sure to clean out /dev & rebuild, and just did so again
:for the ad1 and ad3 devices..
:
:Perhaps I'm misunderstanding the how the new partitions work?
:
:thanks again for investigating
:
:- Chris

    This is because vinum is trying to write into the label area
    for the drive, because you have partition 'a' starting at block #0.

    I saw in the code that vinum was write-enabling the label area,
    but it really shouldn't.  I don't see how it can make such assumptions.
    vinum is eating into the boot2 area of the disklabel (offset 4096 of
    the 8192 byte label area).  Theoretically I could allow this, but it's
    really badly polluting assumptions in the label space.

    The question is whether we can simply require that vinum partitions
    skip the label area (i.e. the starting block has to be at least 16
    for a partition created with a normal disklabel) or whether there
    are backwards compatibility issues that require us to support vinum
    writing into the disk's label area.


					-Matt
					Matthew Dillon 
					<dillon@backplane.com>