Hello,
I''m currently trying to convert a system from Solaris 10 U1 with
Veritas VM
to Solaris 10 U3 with ZFS... the san portion of the server is managed by
Hitachi HDLM 5.8.
I''m seeing two distinct errors... let me know if they are classical or
if I
should open a ticket (bug report)... Thanks in advance ...
When trying to create a pool with the whole luns, I''m getting the
following
error
jumps8002 #format
Unknown controller ''MD21'' - /etc/format.dat (15)
Unknown controller ''MD21'' - /etc/format.dat (20)
Unknown controller ''MD21'' - /etc/format.dat (25)
Unknown controller ''MD21'' - /etc/format.dat (151)
Unknown controller ''MD21'' - /etc/format.dat (155)
Unknown controller ''MD21'' - /etc/format.dat (159)
Unknown controller ''MD21'' - /etc/format.dat (163)
Unknown controller ''MD21'' - /etc/format.dat (167)
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1t0d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci at 1c,600000/scsi at 2/sd at 0,0
1. c1t1d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci at 1c,600000/scsi at 2/sd at 1,0
2. c7t50060E8004758654d0 <HITACHI-OPEN-V-SUN-5006 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,0
3. c7t50060E8004758654d1 <HITACHI-OPEN-V-SUN-5006 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,1
4. c7t50060E8004758654d2 <HITACHI-OPEN-V-SUN-5006 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,2
5. c7t50060E8004758654d3 <HITACHI-OPEN-V-SUN-5005 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,3
6. c7t50060E8004758654d4 <HITACHI-OPEN-V-SUN-5005 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,4
7. c7t50060E8004758654d5 <HITACHI-OPEN-V-SUN-5005 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,5
8. c7t50060E8004758654d6 <HITACHI-OPEN-V-SUN-5005 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,6
9. c7t50060E8004758654d7 <HITACHI-OPEN-V-SUN-5005 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,7
10. c7t50060E8004758654d8 <HITACHI-OPEN-V-SUN-5005 cyl 3821 alt 2 hd
15 sec 512>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,8
- hit space for more or s to select -
jumps8002 #zpool create sanpool c7t50060E8004758654d0 c7t50060E8004758654d1
c7t50060E8004758654d2
cannot open ''/dev/dsk/c7t50060E8004758654d0s0'':
[..]
AVAILABLE DISK SELECTIONS:
0. c1t0d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci at 1c,600000/scsi at 2/sd at 0,0
1. c1t1d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci at 1c,600000/scsi at 2/sd at 1,0
2. c7t50060E8004758654d0 <HITACHI-OPEN-V -SUN-5006-14.00GB>
/pseudo/dlmndrv at 1/dlmfdrv at w50060e8004758654,0
[..]
The first disk listed switched to the EFI format, not the others....
When resetting the disks to the SMI format and attempting to create the same
pool using the s0 slices (after creating them the same on each disk), I do
simply get a panic...
jumps8002:/root #zpool create sanpool c7t50060E8004758654d0s0
c7t50060E8004758654d1s0 c7t50060E8004758654d2s0
panic[cpu1]/thread=30003140320: BAD TRAP: type=31 rp=2a100cbe9d0 addr=0
mmu_fsr=0 occurred in module "dlmfdrv" due to a NULL point
er dereference
zpool: trap type = 0x31
pid=966, pc=0x7b286518, sp=0x2a100cbe271, tstate=0x80001606, context=0x73b
g1-g7: 0, 0, 0, 300031c29c0, 1, 0, 30003140320
000002a100cbe6f0 unix:die+78 (31, 2a100cbe9d0, 0, 0, 2a100cbe7b0, 1076000)
%l0-3: 0000000000001fff 0000000000000031 0000000001000000 0000000000002000
%l4-7: 000000000181a1d8 000000000181a000 0000000000000000 0000000080001606
000002a100cbe7d0 unix:trap+9d4 (2a100cbe9d0, 10000, 1fff, 5, 0, 1)
%l0-3: 0000000000000000 000006000293e7a0 0000000000000031 0000000000000000
%l4-7: ffffffffffffe000 0000000000000000 0000000000000001 0000000000000005
000002a100cbe920 unix:ktl0+48 (70067f58, 30003140320, ffffffffffffffff, 0,
0, 30000072a08)
%l0-3: 0000000000000007 0000000000001400 0000000080001606 000000000101aa04
%l4-7: 0000000070067ee8 0000000070067000 0000000000000000 000002a100cbe9d0
000002a100cbea70 dlmfdrv:HSPLog_Main+704 (11100000008, 42a, 2a100cbf398,
ffffffff80200000, 60000c03e48, 0)
%l0-3: 0000000000000000 0000000000000000 0000060001700354 0000000070067ee8
%l4-7: 0000000070067ef0 0000060001700330 0000000000000008 0000000000000008
000002a100cbeb80 dlmfdrv:dlmfdrv_ioctl+648 (11100000008, 42a, 2a100cbf398,
ffffffff80200000, 60000c03e48, 0)
%l0-3: 000002a100cbf29c 0000060000e422f8 00000000f00ffc00 0000000000000000
%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000001860800
000002a100cbf2e0 zfs:vdev_disk_open+2cc (6000294ba40, 7ffffc00, 2a100cbf470,
1c8, 18a8708, 0)
%l0-3: 00000600016cd6c8 0000000000000016 0000000000000000 000000000000b076
%l4-7: 0000000000000001 0000000000000000 000000000000b075 0000000000000000
000002a100cbf3c0 zfs:vdev_open+108 (6000294ba40, 0, e856b31d2cae2efe,
70446e48, 0, 0)
%l0-3: 0000000000000002 0000000000000001 0000000070446e48 0000000000000001
%l4-7: 0000000000000000 000006000294b500 0000000070422c00 000000007b754ffc
000002a100cbf480 zfs:vdev_root_open+44 (600017f65c0, 2a100cbf5e8,
2a100cbf5e0, 0, 70446298, 70446000)
%l0-3: 000000007b772800 0000000000000001 0000000070446450 0000000000000006
%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000060001733aa8
000002a100cbf530 zfs:vdev_open+108 (600017f65c0, 0, 600014383e8, 70446450,
0, 0)
%l0-3: 0000000000000002 0000000000000000 0000000070446450 0000000000000001
%l4-7: 0000000000000000 0000000000000013 0000000070422c00 000000007b749d0c
000002a100cbf5f0 zfs:vdev_create+4 (600017f65c0, 4, 0, 2, 0, 1)
%l0-3: 0000000070446450 00000600017f65c0 000000007b76fc00 0000000000000002
%l4-7: 0000000000000002 000002a100cbf688 00000600014383c0 0000000000000008
000002a100cbf6a0 zfs:spa_create+e8 (60002aa6000, 600016cd908, 600026c2900,
3, 60002774180, 0)
%l0-3: fffffffffffffff8 0000000000000000 0000000000000000 00000600026c2b70
%l4-7: 00000600026c2ad0 0000000000000004 0000000000000002 0000000000000002
000002a100cbf770 zfs:zfs_ioc_pool_create+44 (60002aa6000, 0, 0, 73,
70446c00, 0)
%l0-3: 0000000000000000 0000060002aa6007 0000060002aa6000 0000000000000073
%l4-7: 0000000000000012 0000000000000032 000000007b773c00 000000007b773c00
000002a100cbf830 zfs:zfsdev_ioctl+160 (70446c00, 0, ffbfa448, 0, 0, 1000)
%l0-3: 0000060002aa6000 0000000000000000 0000000000000000 0000000000000000
%l4-7: 000000007b75a5f4 0000000070446f60 0000000000000000 0000000070446f60
000002a100cbf8e0 genunix:fop_ioctl+20 (6000281abc0, 5a00, ffbfa448, 100003,
60002979cf0, 12066d4)
%l0-3: 0000060001362000 0000060001362000 0000000000000003 000006000293e7a0
%l4-7: 0000000000000000 00000000ff3250c0 0000000000000000 00000000018a9400
000002a100cbf990 genunix:ioctl+184 (3, 60000da98f8, ffbfa448, ffc00049,
1010101, 5a00)
%l0-3: 0000000000000000 0000000000000000 0000000000000004 0000000000008de0
%l4-7: 0000000000000001 0000000000000000 0000000000000000 0000000000000000
syncing file systems... 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 done
(not all i/o completed)
--
Gael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070113/03e13c86/attachment.html>
Richard Elling
2007-Jan-13 20:11 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
Gael wrote:> Hello, > > I''m currently trying to convert a system from Solaris 10 U1 with Veritas > VM to Solaris 10 U3 with ZFS... the san portion of the server is managed > by Hitachi HDLM 5.8. > > I''m seeing two distinct errors... let me know if they are classical or > if I should open a ticket (bug report)... Thanks in advance ... > > When trying to create a pool with the whole luns, I''m getting the > following error > > jumps8002 #format > Unknown controller ''MD21'' - /etc/format.dat (15) > Unknown controller ''MD21'' - /etc/format.dat (20) > Unknown controller ''MD21'' - /etc/format.dat (25) > Unknown controller ''MD21'' - /etc/format.dat (151) > Unknown controller ''MD21'' - /etc/format.dat (155) > Unknown controller ''MD21'' - /etc/format.dat (159) > Unknown controller ''MD21'' - /etc/format.dat (163) > Unknown controller ''MD21'' - /etc/format.dat (167) > Searching for disks...doneSo, what is in your format.dat? I haven''t seen an MD21 in over 15 years. I would have thought that we removed it from format.dat long ago... -- richard
Eric Schrock
2007-Jan-13 20:16 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
On Sat, Jan 13, 2007 at 12:11:26PM -0800, Richard Elling wrote:> > So, what is in your format.dat? I haven''t seen an MD21 in over 15 years. > I would have thought that we removed it from format.dat long ago... > -- richardThis sounds like: 5020503 *format* Unknown controller ''MD21'' warnings Which was due to customer error when a jumpstart symlink was accidentally grabbing information from a Solaris 9 environment. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On 1/13/07, Richard Elling <Richard.Elling at sun.com> wrote:> > Gael wrote: > > Hello, > > > > I''m currently trying to convert a system from Solaris 10 U1 with Veritas > > VM to Solaris 10 U3 with ZFS... the san portion of the server is managed > > by Hitachi HDLM 5.8. > > > > I''m seeing two distinct errors... let me know if they are classical or > > if I should open a ticket (bug report)... Thanks in advance ... > > > > When trying to create a pool with the whole luns, I''m getting the > > following error > > > > jumps8002 #format > > Unknown controller ''MD21'' - /etc/format.dat (15) > > Unknown controller ''MD21'' - /etc/format.dat (20) > > Unknown controller ''MD21'' - /etc/format.dat (25) > > Unknown controller ''MD21'' - /etc/format.dat (151) > > Unknown controller ''MD21'' - /etc/format.dat (155) > > Unknown controller ''MD21'' - /etc/format.dat (159) > > Unknown controller ''MD21'' - /etc/format.dat (163) > > Unknown controller ''MD21'' - /etc/format.dat (167) > > Searching for disks...done > > So, what is in your format.dat? I haven''t seen an MD21 in over 15 years. > I would have thought that we removed it from format.dat long ago... > -- richard >jumps8002:/etc/apache2 #cat /etc/release Solaris 10 11/06 s10s_u3wos_10 SPARC Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 14 November 2006 The file is a little bit too long to flood the list with it, here a quick grep jumps8002:/etc/apache2 #cat /etc/format.dat |grep MD21 # This is the list of supported disks for the Emulex MD21 controller. : ctlr = MD21 \ : ctlr = MD21 \ : ctlr = MD21 \ # This is the list of partition tables for the Emulex MD21 controller. : disk = "Micropolis 1355" : ctlr = MD21 \ : disk = "Micropolis 1355" : ctlr = MD21 \ : disk = "Toshiba MK 156F" : ctlr = MD21 \ : disk = "Micropolis 1558" : ctlr = MD21 \ : disk = "Micropolis 1558" : ctlr = MD21 \ -- Gael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070113/ee981667/attachment.html>
On 1/13/07, Eric Schrock <eric.schrock at sun.com> wrote:> > On Sat, Jan 13, 2007 at 12:11:26PM -0800, Richard Elling wrote: > > > > So, what is in your format.dat? I haven''t seen an MD21 in over 15 > years. > > I would have thought that we removed it from format.dat long ago... > > -- richard > > This sounds like: > > 5020503 *format* Unknown controller ''MD21'' warnings > > Which was due to customer error when a jumpstart symlink was > accidentally grabbing information from a Solaris 9 environment. > > - Eric > > -- > Eric Schrock, Solaris Kernel Development > http://blogs.sun.com/eschrock >Eric, My issue is not the MD21 error which has been into solaris since a long time, but the inability to create a pool with a HDLM device.... Did try to search on sunsolve but no luck on that one... same with the Hitachi site, and no luck either, googling right now and thinking to switch to MPxIO as I need to get that machine back online before monday... Regards -- Gael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070113/016f3109/attachment.html>
Eric Schrock
2007-Jan-13 20:27 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
On Sat, Jan 13, 2007 at 01:30:19PM -0600, Gael wrote:> Hello, > > jumps8002 #zpool create sanpool c7t50060E8004758654d0 c7t50060E8004758654d1 > c7t50060E8004758654d2 > cannot open ''/dev/dsk/c7t50060E8004758654d0s0'':This is a strange error, can you do a ''truss -topen'' of this process? Does the automatic EFI label work? Does the ''s0'' slice exist after labelling the disk? Can you manually create an EFI label using format?> jumps8002:/root #zpool create sanpool c7t50060E8004758654d0s0 > c7t50060E8004758654d1s0 c7t50060E8004758654d2s0 > > panic[cpu1]/thread=30003140320: BAD TRAP: type=31 rp=2a100cbe9d0 addr=0 > mmu_fsr=0 occurred in module "dlmfdrv" due to a NULL point > er dereferenceThis is clearly a bug in the driver. The driver is not behaving correctly in reponse to either the DKIOCSETWCE or DKIOCGMEDIAINFO ioctl(). - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On 1/13/07, Eric Schrock <eric.schrock at sun.com> wrote:> > On Sat, Jan 13, 2007 at 01:30:19PM -0600, Gael wrote: > > Hello, > > > > jumps8002 #zpool create sanpool c7t50060E8004758654d0 > c7t50060E8004758654d1 > > c7t50060E8004758654d2 > > cannot open ''/dev/dsk/c7t50060E8004758654d0s0'': > > This is a strange error, can you do a ''truss -topen'' of this process? > Does the automatic EFI label work? Does the ''s0'' slice exist after > labelling the disk? Can you manually create an EFI label using format?The truss is attached to that email, after running the zpool against the whole luns (not specifying s0 in the command line), the first device listed is converted to EFI, the two others remains in SMI selecting c7t50060E8004758654d0 [disk formatted] partition> p Current partition table (original): Total disk sectors available: 29344222 + 16384 (reserved sectors) Part Tag Flag First Sector Size Last Sector 0 usr wm 34 13.99GB 29344222 1 unassigned wm 0 0 0 2 unassigned wm 0 0 0 3 unassigned wm 0 0 0 4 unassigned wm 0 0 0 5 unassigned wm 0 0 0 6 unassigned wm 0 0 0 8 reserved wm 29344223 8.00MB 29360606 If I go and create the s0 slice on the second lun, it works perfectly... partition> p Current partition table (original): Total disk cylinders available: 3821 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 0 - 3820 13.99GB (3821/0/0) 29345280 1 unassigned wu 0 0 (0/0/0) 0 2 backup wu 0 - 3820 13.99GB (3821/0/0) 29345280 3 unassigned wu 0 0 (0/0/0) 0 4 unassigned wu 0 0 (0/0/0) 0 5 unassigned wu 0 0 (0/0/0) 0 6 unassigned wu 0 0 (0/0/0) 0 7 unassigned wu 0 0 (0/0/0) 0 partition> label [0] SMI Label [1] EFI Label Specify Label type[0]: 1 Warning: This disk has an SMI label. Changing to EFI label will erase all current partitions. Continue? y partition> p Current partition table (original): Total disk sectors available: 29344222 + 16384 (reserved sectors) Part Tag Flag First Sector Size Last Sector 0 root wm 34 13.99GB 29344221 1 unassigned wm 0 0 0 2 unassigned wm 0 0 0 3 unassigned wm 0 0 0 4 unassigned wm 0 0 0 5 unassigned wm 0 0 0 6 unassigned wm 0 0 0 7 unassigned wm 0 0 0 8 reserved wm 29344222 8.00MB 29360605> jumps8002:/root #zpool create sanpool c7t50060E8004758654d0s0 > > c7t50060E8004758654d1s0 c7t50060E8004758654d2s0 > > > > panic[cpu1]/thread=30003140320: BAD TRAP: type=31 rp=2a100cbe9d0 addr=0 > > mmu_fsr=0 occurred in module "dlmfdrv" due to a NULL point > > er dereference > > This is clearly a bug in the driver. The driver is not behaving > correctly in reponse to either the DKIOCSETWCE or DKIOCGMEDIAINFO > ioctl(). > > - Eric > > -- > Eric Schrock, Solaris Kernel Development > http://blogs.sun.com/eschrock >-- Gael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070113/75a81697/attachment.html> -------------- next part -------------- open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT open("/lib/libzfs.so.2", O_RDONLY) = 3 open("/lib/libnvpair.so.1", O_RDONLY) = 3 open("/lib/libdevid.so.1", O_RDONLY) = 3 open("/lib/libefi.so.1", O_RDONLY) = 3 open("/usr/lib/libdiskmgt.so.1", O_RDONLY) = 3 open("/lib/libuutil.so.1", O_RDONLY) = 3 open("/lib/libumem.so.1", O_RDONLY) = 3 open("/lib/libc.so.1", O_RDONLY) = 3 open("/lib/libm.so.2", O_RDONLY) = 3 open("/lib/libdevinfo.so.1", O_RDONLY) = 3 open("/lib/libgen.so.1", O_RDONLY) = 3 open("/lib/libnsl.so.1", O_RDONLY) = 3 open("/lib/libuuid.so.1", O_RDONLY) = 3 open("/lib/libadm.so.1", O_RDONLY) = 3 open("/lib/libkstat.so.1", O_RDONLY) = 3 open("/lib/libsysevent.so.1", O_RDONLY) = 3 open("/usr/lib/libvolmgt.so.1", O_RDONLY) = 3 open("/lib/libsec.so.1", O_RDONLY) = 3 open("/lib/libsocket.so.1", O_RDONLY) = 3 open("/lib/libdoor.so.1", O_RDONLY) = 3 open("/lib/libavl.so.1", O_RDONLY) = 3 open("/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1", O_RDONLY) = 3 open("/dev/zfs", O_RDWR) = 3 open("/etc/mnttab", O_RDONLY) = 4 open("/etc/dfs/sharetab", O_RDONLY) Err#2 ENOENT open("/dev/.devlink_db", O_RDONLY) = 5 open("/devices/pseudo/devinfo at 0:devinfo", O_RDONLY) = 6 open("/dev/openprom", O_RDONLY) = 6 open("/devices/pseudo/devinfo at 0:devinfo", O_RDONLY) = 7 open("/devices/pseudo/devinfo at 0:devinfo", O_RDONLY) = 7 open("/etc/mnttab", O_RDONLY) = 5 open("/var/run/sysevent_channels/syseventd_channel/16", O_RDWR|O_CREAT, 0600) = 5 /1: open("/var/run/sysevent_channels/syseventd_channel/reg_door", O_RDONLY) = 5 /1: open("/var/run/sysevent_channels/syseventd_channel/reg_door", O_RDONLY) = 5 /1: open("/var/run/sysevent_channels/syseventd_channel/reg_door", O_RDONLY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s0", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s0", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s1", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s2", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s3", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s4", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s5", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s6", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s7", O_RDONLY|O_NDELAY) = 5 /1: open("/dev/rdsk/c7t50060E8004758654d0s0", O_RDONLY|O_NDELAY) = 5 /1: open("/etc/mnttab", O_RDONLY) = 5 /4: open("/etc/mnttab", O_RDONLY) = 5 /1: open("/usr/lib/libmeta.so", O_RDONLY) = 7 /1: open("/lib/libscf.so.1", O_RDONLY) = 7 /1: open("/lib/libmd5.so.1", O_RDONLY) = 7 /1: open("/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1", O_RDONLY) = 7 /1: open("/lib/libmp.so.2", O_RDONLY) = 7 /1: open64("/dev/md/admin", O_RDWR) = 7 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open64("/dev/rdsk/c1t0d0s7", O_RDONLY|O_NDELAY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open64("/dev/rdsk/c1t1d0s7", O_RDONLY|O_NDELAY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/vfstab", O_RDONLY) = 8 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 8 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 8 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 8 /1: open("/etc/netconfig", O_RDONLY|O_LARGEFILE) = 8 /1: open("/dev/udp", O_RDONLY) = 8 /1: open("/dev/udp", O_RDONLY) = 8 /1: open64("/var/run/name_service_door", O_RDONLY) = 8 /1: open("/dev/udp", O_RDWR) = 9 /1: open("/dev/tcp", O_RDWR) = 9 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/svc/volatile/repository_door", O_RDONLY) = 10 /1: open("/etc/mnttab", O_RDONLY) = 10 /1: open("/var/run/sysevent_channels/syseventd_channel/17", O_RDWR|O_CREAT, 0600) = 10 /4: open("/etc/mnttab", O_RDONLY) = 12 /1: open("/var/run/sysevent_channels/syseventd_channel/reg_door", O_RDONLY) = 10 /1: open("/var/run/sysevent_channels/syseventd_channel/reg_door", O_RDONLY) = 10 /1: open("/dev/zfs", O_RDWR) = 10 /1: open("/etc/mnttab", O_RDONLY) = 12 /1: open("/etc/dfs/sharetab", O_RDONLY) Err#2 ENOENT /1: open("/dev/dsk/c7t50060E8004758654d0s0", O_RDONLY) = 13 /1: open("/var/run/dm_lu_Rxayjc", O_RDWR|O_CREAT|O_EXCL, 0600) = 13 /1: open("/dev/dump", O_RDONLY) = 13 /1: open("/dev/dsk/c7t50060E8004758654d0s0", O_RDONLY) = 14 /1: open("/etc/vfstab", O_RDONLY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d0s0", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/dsk/c7t50060E8004758654d0s2", O_RDONLY) = 14 /1: open("/dev/dsk/c7t50060E8004758654d0s2", O_RDONLY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s0", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s0", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s1", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s2", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s3", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s4", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s5", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s6", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s7", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s0", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/dsk/c7t50060E8004758654d1s0", O_RDONLY) = 14 /1: open("/dev/dsk/c7t50060E8004758654d1s0", O_RDONLY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d1s0", O_RDONLY|O_NDELAY) = 14 /1: open("/dev/dsk/c7t50060E8004758654d1s2", O_RDONLY) = 14 /1: open("/dev/dsk/c7t50060E8004758654d1s2", O_RDONLY) = 14 /1: open("/dev/rdsk/c7t50060E8004758654d0s2", O_RDWR|O_NDELAY) = 14 /1: open("/dev/urandom", O_RDONLY) = 15 /1: open("/dev/urandom", O_RDONLY) = 15 /1: open("/dev/urandom", O_RDONLY) = 15 /1: open("/dev/urandom", O_RDONLY) = 15 /1: open("/dev/urandom", O_RDONLY) = 15 /1: open("/dev/urandom", O_RDONLY) = 15 /1: open("/dev/dsk/c7t50060E8004758654d0s0", O_RDONLY) Err#48 ENOTSUP
Joerg Schilling
2007-Jan-13 21:38 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
Eric Schrock <eric.schrock at sun.com> wrote:> On Sat, Jan 13, 2007 at 12:11:26PM -0800, Richard Elling wrote: > > > > So, what is in your format.dat? I haven''t seen an MD21 in over 15 years. > > I would have thought that we removed it from format.dat long ago... > > -- richard > > This sounds like: > > 5020503 *format* Unknown controller ''MD21'' warningsI don''t understand these warnings as the MD21 is the first controller that _really_ supports inquiry. Sformat may output some ACB-5500 warnings wich is the first controller that replies to inquiry but sends a completely nulled block that was OK for a disk controller at these times. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Richard Elling
2007-Jan-14 01:40 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
Gael wrote:> jumps8002:/etc/apache2 #cat /etc/release > Solaris 10 11/06 s10s_u3wos_10 SPARC > Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 14 November 2006 > > The file is a little bit too long to flood the list with it, here a > quick grep > > jumps8002:/etc/apache2 #cat /etc/format.dat |grep MD21 > # This is the list of supported disks for the Emulex MD21 controller. > : ctlr = MD21 \ > : ctlr = MD21 \ > : ctlr = MD21 \ > # This is the list of partition tables for the Emulex MD21 controller. > : disk = "Micropolis 1355" : ctlr = MD21 \ > : disk = "Micropolis 1355" : ctlr = MD21 \ > : disk = "Toshiba MK 156F" : ctlr = MD21 \ > : disk = "Micropolis 1558" : ctlr = MD21 \ > : disk = "Micropolis 1558" : ctlr = MD21 \As I thought. That /etc/format.dat probably didn''t come from Solaris 10, or at least I don''t see those entries in NV. FWIW, the Micropolis 1355 is a 141 MByte (!) ESDI disk. The MD21 is an ESDI to SCSI converter. -- richard
Torrey McMahon
2007-Jan-14 01:59 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
Richard Elling wrote:> Gael wrote: >> jumps8002:/etc/apache2 #cat /etc/release >> Solaris 10 11/06 s10s_u3wos_10 SPARC >> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. >> Use is subject to license terms. >> Assembled 14 November 2006 >> >> The file is a little bit too long to flood the list with it, here a >> quick grep >> >> jumps8002:/etc/apache2 #cat /etc/format.dat |grep MD21 >> # This is the list of supported disks for the Emulex MD21 controller. >> : ctlr = MD21 \ >> : ctlr = MD21 \ >> : ctlr = MD21 \ >> # This is the list of partition tables for the Emulex MD21 controller. >> : disk = "Micropolis 1355" : ctlr = MD21 \ >> : disk = "Micropolis 1355" : ctlr = MD21 \ >> : disk = "Toshiba MK 156F" : ctlr = MD21 \ >> : disk = "Micropolis 1558" : ctlr = MD21 \ >> : disk = "Micropolis 1558" : ctlr = MD21 \ > > As I thought. That /etc/format.dat probably didn''t come from Solaris 10, > or at least I don''t see those entries in NV. > > FWIW, the Micropolis 1355 is a 141 MByte (!) ESDI disk. The MD21 is an > ESDI to SCSI converter.Maybe it''s time to clean that file up? Do we even need it anymore?
Cindy Swearingen
2007-Jan-16 18:52 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
Hi Torrey, The MD21 entries were removed from the /etc/format.dat file in the Solaris 10 release although the controller itself was EOL''d long before this release. However, the entries are not removed upon upgrade from a previous release, which is this bug: http://bugs.opensolaris.org/view_bug.do?bug_id=5023396 Cindy Torrey McMahon wrote:> Richard Elling wrote: > >> Gael wrote: >> >>> jumps8002:/etc/apache2 #cat /etc/release >>> Solaris 10 11/06 s10s_u3wos_10 SPARC >>> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. >>> Use is subject to license terms. >>> Assembled 14 November 2006 >>> >>> The file is a little bit too long to flood the list with it, here a >>> quick grep >>> >>> jumps8002:/etc/apache2 #cat /etc/format.dat |grep MD21 >>> # This is the list of supported disks for the Emulex MD21 controller. >>> : ctlr = MD21 \ >>> : ctlr = MD21 \ >>> : ctlr = MD21 \ >>> # This is the list of partition tables for the Emulex MD21 controller. >>> : disk = "Micropolis 1355" : ctlr = MD21 \ >>> : disk = "Micropolis 1355" : ctlr = MD21 \ >>> : disk = "Toshiba MK 156F" : ctlr = MD21 \ >>> : disk = "Micropolis 1558" : ctlr = MD21 \ >>> : disk = "Micropolis 1558" : ctlr = MD21 \ >> >> >> As I thought. That /etc/format.dat probably didn''t come from Solaris 10, >> or at least I don''t see those entries in NV. >> >> FWIW, the Micropolis 1355 is a 141 MByte (!) ESDI disk. The MD21 is an >> ESDI to SCSI converter. > > > > Maybe it''s time to clean that file up? Do we even need it anymore? > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
All, And on that one big mea culpa, the wanboot.conf install file used the solaris 9 miniroot to load that solaris 10 U3 machine... explaining why the MD21 lines appeared on that machine ... (last time I do play lazy admin and don''t refresh the whole wanboot config files before loading Solaris 10 ...) On the other hand, MPxIO and ZFS appears to work great with that Hitachi array... the only concern as of today is that people are asking how to simulate the dlnkmgr view -drv with MPxIO. Any ideas ? Regards Gael On 1/16/07, Cindy Swearingen <Cindy.Swearingen at sun.com> wrote:> > Hi Torrey, > > The MD21 entries were removed from the /etc/format.dat file in the > Solaris 10 release although the controller itself was EOL''d long > before this release. > > However, the entries are not removed upon upgrade from a previous > release, which is this bug: > > http://bugs.opensolaris.org/view_bug.do?bug_id=5023396 > > > Cindy > > Torrey McMahon wrote: > > Richard Elling wrote: > > > >> Gael wrote: > >> > >>> jumps8002:/etc/apache2 #cat /etc/release > >>> Solaris 10 11/06 s10s_u3wos_10 SPARC > >>> Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > >>> Use is subject to license terms. > >>> Assembled 14 November 2006 > >>> > >>> The file is a little bit too long to flood the list with it, here a > >>> quick grep > >>> > >>> jumps8002:/etc/apache2 #cat /etc/format.dat |grep MD21 > >>> # This is the list of supported disks for the Emulex MD21 controller. > >>> : ctlr = MD21 \ > >>> : ctlr = MD21 \ > >>> : ctlr = MD21 \ > >>> # This is the list of partition tables for the Emulex MD21 controller. > >>> : disk = "Micropolis 1355" : ctlr = MD21 \ > >>> : disk = "Micropolis 1355" : ctlr = MD21 \ > >>> : disk = "Toshiba MK 156F" : ctlr = MD21 \ > >>> : disk = "Micropolis 1558" : ctlr = MD21 \ > >>> : disk = "Micropolis 1558" : ctlr = MD21 \ > >> > >> > >> As I thought. That /etc/format.dat probably didn''t come from Solaris > 10, > >> or at least I don''t see those entries in NV. > >> > >> FWIW, the Micropolis 1355 is a 141 MByte (!) ESDI disk. The MD21 is an > >> ESDI to SCSI converter. > > > > > > > > Maybe it''s time to clean that file up? Do we even need it anymore? > > > > > > > > _______________________________________________ > > zfs-discuss mailing list > > zfs-discuss at opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-- Gael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070116/edd1c23c/attachment.html>
Torrey McMahon
2007-Jan-16 22:52 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
What does that view show? Gael wrote:> All, > > And on that one big mea culpa, the wanboot.conf install file used the > solaris 9 miniroot to load that solaris 10 U3 machine... > explaining why the MD21 lines appeared on that machine ... (last time > I do play lazy admin and don''t refresh the whole wanboot config files > before loading Solaris 10 ...) > > On the other hand, MPxIO and ZFS appears to work great with that > Hitachi array... the only concern as of today is that people are > asking how to simulate the dlnkmgr view -drv with MPxIO. Any ideas ? > > Regards > > Gael > > > On 1/16/07, *Cindy Swearingen* <Cindy.Swearingen at sun.com > <mailto:Cindy.Swearingen at sun.com>> wrote: > > Hi Torrey, > > The MD21 entries were removed from the /etc/format.dat file in the > Solaris 10 release although the controller itself was EOL''d long > before this release. > > However, the entries are not removed upon upgrade from a previous > release, which is this bug: > > http://bugs.opensolaris.org/view_bug.do?bug_id=5023396 > <http://bugs.opensolaris.org/view_bug.do?bug_id=5023396> > > > Cindy > > Torrey McMahon wrote: > > Richard Elling wrote: > > > >> Gael wrote: > >> > >>> jumps8002:/etc/apache2 #cat /etc/release > >>> Solaris 10 11/06 s10s_u3wos_10 SPARC > >>> Copyright 2006 Sun Microsystems, Inc. All Rights > Reserved. > >>> Use is subject to license terms. > >>> Assembled 14 November 2006 > >>> > >>> The file is a little bit too long to flood the list with it, > here a > >>> quick grep > >>> > >>> jumps8002:/etc/apache2 #cat /etc/format.dat |grep MD21 > >>> # This is the list of supported disks for the Emulex MD21 > controller. > >>> : ctlr = MD21 \ > >>> : ctlr = MD21 \ > >>> : ctlr = MD21 \ > >>> # This is the list of partition tables for the Emulex MD21 > controller. > >>> : disk = "Micropolis 1355" : ctlr = MD21 \ > >>> : disk = "Micropolis 1355" : ctlr = MD21 \ > >>> : disk = "Toshiba MK 156F" : ctlr = MD21 \ > >>> : disk = "Micropolis 1558" : ctlr = MD21 \ > >>> : disk = "Micropolis 1558" : ctlr = MD21 \ > >> > >> > >> As I thought. That /etc/format.dat probably didn''t come from > Solaris 10, > >> or at least I don''t see those entries in NV. > >> > >> FWIW, the Micropolis 1355 is a 141 MByte (!) ESDI disk. The > MD21 is an > >> ESDI to SCSI converter. > > > > > > > > Maybe it''s time to clean that file up? Do we even need it anymore? > > > > > > > > _______________________________________________ > > zfs-discuss mailing list > > zfs-discuss at opensolaris.org <mailto:zfs-discuss at opensolaris.org> > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org <mailto:zfs-discuss at opensolaris.org> > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > > > -- > Gael
This command is often used to identify the physical disk linked to the LUN (iLu) to allow the San team to deallocate/identify the right physical disk(s) etc... vsmd8008:/root #/opt/DynamicLinkManager/bin/dlnkmgr view -drv PathID HDevName Device LDEV 000000 c4t50060E8004572420d71 ssd2 USP.0022308.10B1 000001 c4t50060E8004572420d0 ssd143 USP.0022308.106A Tried to play with the mpathadm command but didn''t find anything close Regards Gael On 1/16/07, Torrey McMahon <tmcmahon2 at yahoo.com> wrote:> > What does that view show? > > Gael wrote: > > All, > > > > And on that one big mea culpa, the wanboot.conf install file used the > > solaris 9 miniroot to load that solaris 10 U3 machine... > > explaining why the MD21 lines appeared on that machine ... (last time > > I do play lazy admin and don''t refresh the whole wanboot config files > > before loading Solaris 10 ...) > > > > On the other hand, MPxIO and ZFS appears to work great with that > > Hitachi array... the only concern as of today is that people are > > asking how to simulate the dlnkmgr view -drv with MPxIO. Any ideas ? > > > > Regards > > > > Gael > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070116/969fd44d/attachment.html>
Torrey McMahon
2007-Jan-17 17:54 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ?
There looks to be code in the DLM package that either
Connects to the HDS box and queries for some info
or
Reads some attributes in the SCSI mode pages to get the info. (I''m
guessing this one.)
In any case HDS would have to share said knowledge with Sun so the
correct information could be obtained and displayed because, as of
today, there is nothing that will get that info.
Gael wrote:> This command is often used to identify the physical disk linked to the
> LUN (iLu) to allow the San team to deallocate/identify the right
> physical disk(s) etc...
>
> vsmd8008:/root #/opt/DynamicLinkManager/bin/dlnkmgr view -drv
> PathID HDevName Device LDEV
> 000000 c4t50060E8004572420d71 ssd2 USP.0022308.10B1
> 000001 c4t50060E8004572420d0 ssd143 USP.0022308.106A
>
> Tried to play with the mpathadm command but didn''t find anything
close
>
> Regards
>
> Gael
>
>
> On 1/16/07, *Torrey McMahon* <tmcmahon2 at yahoo.com
> <mailto:tmcmahon2 at yahoo.com>> wrote:
>
> What does that view show?
>
> Gael wrote:
> > All,
> >
> > And on that one big mea culpa, the wanboot.conf install file
> used the
> > solaris 9 miniroot to load that solaris 10 U3 machine...
> > explaining why the MD21 lines appeared on that machine ... (last
> time
> > I do play lazy admin and don''t refresh the whole wanboot
config
> files
> > before loading Solaris 10 ...)
> >
> > On the other hand, MPxIO and ZFS appears to work great with that
> > Hitachi array... the only concern as of today is that people are
> > asking how to simulate the dlnkmgr view -drv with MPxIO. Any
> ideas ?
> >
> > Regards
> >
> > Gael
> >
> >
>
Rob Logan
2007-Jan-23 16:11 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ? [MD21]
> FWIW, the Micropolis 1355 is a 141 MByte (!) ESDI disk.> The MD21 is an ESDI to SCSI converter. yup... its the board in the middle left of http://rob.com/sun/sun2/md21.jpg Rob
Joerg Schilling
2007-Jan-23 16:48 UTC
[zfs-discuss] ZFS and HDLM 5.8 ... does that coexist well ? [MD21]
Rob Logan <Rob at Logan.com> wrote:> > FWIW, the Micropolis 1355 is a 141 MByte (!) ESDI disk. > > The MD21 is an ESDI to SCSI converter. > > yup... its the board in the middle left of > http://rob.com/sun/sun2/md21.jpgIf you are talking about the middle right, this is a ACB-4000 series controller from Adaptec. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily