DragonFlyBSD

[..]

So.. I know vinum isn't used by everyone.. if this sounds like the
problem, I can try to take a crack at fixing it, but I doubt I can make
the release branch .. e.g ~1 week at the earliest, owing to my n00b-ness..

sorry, that slipped through :/

I tried to adapt vinum to the new disk layer, but something fishy is going on and I couldn't track it down. I'll try to have a look.

cheers
simon

no worries - glad someones looking at it.. :)

good luck.

- Chris

:sorry, that slipped through :/
:
:I tried to adapt vinum to the new disk layer, but something fishy is goin=
:g on and I couldn't track it down. I'll try to have a look.
:
:cheers
: simon

We'll need this working for the release.  I'd be happy to take a shot at
    it if you don't have time.  I don't know if you intended that device
    to access via the disk layer or to access the vinum driver directly.
    Normally the disk layer takes care of DIOCGPART.

-Matt

Ok, newfs should now work on volumess. Please test vinum some more.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Thanks for checking this out.. reviewing the patch, there's no way I
would have figured all that out in that amount of time..

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

: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>

The problem is rather that you can place a partition into the label area. This should be off limits.

cheers
simon

confirming bumping start up to 16 (per your 8192 number) clears this up,
as well as bumping up to 10 (per sizeof(struct dfly_disklabel)) .

Seeing as it seems like I'm the only one using this,
I'm okay to break backwords compat. :)

just kidding.. sort-of.

- Chris

:The problem is rather that you can place a partition into the label area. This should be off limits.
:
:cheers
: simon

It's a non-issue with GPT partitions or DragonFly 64 bit disklabels,
    since those won't let you create a partition which overlaps the GPT
    or disklabel headers.

We don't have boot support for dragonfly 64 bit disklabels yet.  That's
    on my list to take a look at after the release.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Matthew Dillon wrote:

More seriously, I'm not sure if an existing configuration would be
forwards-compatible anyway due to the new label changes if someone had
used 'raw' slices, etc.

Although having to shift the on-disk filesystem layout for upgrade is a
different kind of animal compared to a 'dumpconfig', 'edit slice cfg in
file' 'recreate vinum setup' kind of a change, especially if you have
lots of data on the drives and have to copy it elsewhere to do the shift

I don't have anything setup with a vinum root disk, so not sure if that
is working / related to this portion of the code or not. Hopefully I'll
get around to testing vinum boot one day, but it hasn't arrived yet ..
Without knowing what the in-boot2-location code does thats probably all
I can say without spewing (more :) hot air onto the topic..

I suppose that's a brainstorm for possible impact..

- Chris

alright.. scratch all the last message.. whatever is kept there looks to
be related to saving the cfg across boots.. investigating.