GEOM_FOX woes

Hi,

I tried to use geom_fox to implement multipathing on my machine. The setup
is: Dell PowerEdge 2600, 2 QLogic 2312 FC Adapters, 2 Brocade 2800 Switches,
1 Compaq HSG 80 FC array with 2 redundant FC controllers. I wrote the magic
labels on the disks, according to the script in the announce message:

       http://lists.freebsd.org/pipermail/freebsd-current/2003-June/005288.html

After reboot, none of the devices ending with .fox were writeable. The
original disks (da??c) were unwriteable either. geom_fox detects the devices
just fine. Here is the snippet from dmesg, after loading geom_fox:

    Creating new fox (da13)
    fox da13.fox lock 0xcb3a5e14
    Creating new fox (da12)
    fox da12.fox lock 0xcb3a5c14
    Creating new fox (da11)
    fox da11.fox lock 0xcb3a5994
    Creating new fox (da10)
    fox da10.fox lock 0xcb3a5814
    Creating new fox (da9)
    fox da9.fox lock 0xcb3a5614
    Creating new fox (da8)
    fox da8.fox lock 0xcb3a5f14
    Creating new fox (da7)
    fox da7.fox lock 0xcb3b1d94
    Adding path (da6) to fox (da13.fox)
    Adding path (da5) to fox (da12.fox)
    Adding path (da4) to fox (da11.fox)

[...similar messages...]

    Adding path (da0c) to fox (da7.fox)
    Removing path (da0) from fox (da7.fox)
    Removing path (da0c) from fox (da7.fox)
    Adding path (da0) to fox (da7.fox)
    Adding path (da0c) to fox (da7.fox)

I don't know why the paths to da0 and da0c were removed by geom_fox. There
is no connectivity problem for sure. I don't know why there are separate
paths to both da0 and da0c. Regarding the problem with incosistent naming
(which is crucial for safely rebooting the machine), I would suggest naming
the devices after the magic ID written on disk, which would be much
more consistent and meaningful than chosing between multiple device names.

Thanks, /S