Sanjay,
1. When I wrote ..."SVM has problems with them." (i.e. with long
device names) I meant - it's impossible to make these devices the part
of metaset(s).
In my case (SunCluster+SVM+MPxIO) it means - I cannot work with these
devices at all. In the SunCluster environment the metasets are
mandatory.

2. I agree with your summary except the name "64 byte vdp"
64 bytes it's a target name length - the length of Y in the cXtYdZs0 notation.
To be precise, the evpd page 0x83 INQUIRY page is not 64 bytes long -
in our case it's 40 bytes long:

# /etc/vx/diag.d/vxdmpinq -d -e 1 -p 131 /dev/rdsk/c6t100000062B09FA34d0s2

Inquiry for /dev/rdsk/c6t100000062B09FA34d0s2, evpd 0x1, page code 0x83
        /dev/rdsk/c6t100000062B09FA34d0s2: Raw data size 40
Bytes 0 - 9      0x00  0x83  0x00  0x24  0x02  0x01  0x00  0x20  0x58  0x49
Bytes 10 - 19    0x56  0x2d  0x49  0x4e  0x43  0x20  0x58  0x49  0x56  0x31
Bytes 20 - 29    0x30  0x33  0x30  0x20  0x20  0x20  0x20  0x20  0x31  0x30
Bytes 30 - 39    0x31  0x34  0x30  0x20  0x20  0x20  0x20  0x20  0x31  0x33

Regards,
-- Leon

On 1/25/06, Sanjay Nadkarni <Sanjay.Nadkarni at sun.com> wrote:
>
> But even this is not completely correct. Since you were able to create
> metadevices on that disk when it was not part of the diskset. I am
> attaching your email to me regarding this, which I am including below.
>
> To summerize I believe here's how things stand.
>
> 1. Without mpxio using the 64 byte vdp one can add disks into the diskset.
>
> 2. With mpxio enabled using the 64 byte vdp, adding that disk to the
> disk fails.
>
> 3. With mpxio enabled, one can create metadevices (stripe in the example
> below) on that disk with 64 byte vdp.
>
> 4. With 16 byte vdp, everything works fine, i.e. no failures are seen
> for the steps described above.
>
> -Sanjay
>
>
> > Sanjay,
> > did I understand you correctly? Do you mean to create a strip on the
> > "problematic" disk w/o creating the metaset?
> > I did it and it worked:
> >
> > Single:
> > # metainit d10 1 1
> > c6t58495620202020204E4558545241202020202020313032353020202020202031d0s0
> > d10: Concat/Stripe is setup
> >
> > Stripe:
> > # metainit d20 1 2
> > c6t58495620202020204E4558545241202020202020313032353020202020202033d0s0
> > c6t58495620202020204E4558545241202020202020313032353020202020202034d0s0
> > d20: Concat/Stripe is setup
> > # metastat
> > d20: Concat/Stripe
> >     Size: 491520 blocks (240 MB)
> >     Stripe 0: (interlace: 1024 blocks)
> >         Device
> > Start Block  Dbase   Reloc
> >
> > /dev/dsk/c6t58495620202020204E45585452412020202020203130323530202020202020
> > 33d0s0          0     No      Yes
> >
> > /dev/dsk/c6t58495620202020204E45585452412020202020203130323530202020202020
> > 34d0s0      16384     No      Yes
> >
> > d10: Concat/Stripe
> >     Size: 33505280 blocks (15 GB)
> >     Stripe 0:
> >         Device
> > Start Block  Dbase   Reloc
> >
> > /dev/dsk/c6t58495620202020204E45585452412020202020203130323530202020202020
> > 31d0s0          0     No      Yes
> >
> > Device Relocation Information:
> > Device
> > Reloc  Device ID
> > /dev/dsk/c6t58495620202020204E45585452412020202020203130323530202020202020
> > 33d0   Yes    id1,ssd at TXIV_____NEXTRA______10250______3
> > /dev/dsk/c6t58495620202020204E45585452412020202020203130323530202020202020
> > 34d0   Yes    id1,ssd at TXIV_____NEXTRA______10250______4
> > /dev/dsk/c6t58495620202020204E45585452412020202020203130323530202020202020
> > 31d0   Yes    id1,ssd at TXIV_____NEXTRA______10250______1
> >
> > Regards,
> > -- Leon
> >
> >
>
>
> Leon Koll wrote:
> > Hi Tom,
> > do you work with device names long like this one:
> > /dev/dsk/c6t<64bytes>d0s0
> > What I see that SVM has problems with them.
> >
> > -- Leon
> >
> >
> > On 1/25/06, Tom Whitten <thomas.whitten at sun.com> wrote:
> >
> >>You're URL says "When the MPxIO is enabled, the SVM cannot work with disks
> >>with long device names (64 bytes target name length)."  We do, however,
> >>have SVM running with MPXIO and long device names.  Can you provide more
> >>details?
> >>
> >>tom
> >>
> >>Leon Koll writes:
> >>
> >>>[i][b]I found the problem!!![/b][/i]
> >>>Looks like a bug in SVM.
> >>>Read here: http://napobo3.blogspot.com/2006/01/i-found-problem.html
> >>>This message posted from opensolaris.org
> >>>_______________________________________________
> >>>lvm-discuss mailing list
> >>>lvm-discuss at opensolaris.org
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>_______________________________________________
> >>lvm-discuss mailing list
> >>lvm-discuss at opensolaris.org
>
>

Reply via email to