UNCLASSIFIED Hi Joel,
Yes you are correct. If you initialise the disk, then it will have a new disk media name. You really want it to have the same name as before. So, don't initialise with option 1, just replace with option 5, and it will keep the same disk media name. Can you show vxprint output? I'm wondering what is being recovered. Is it anything to do with silo2dg? Yes, it can get confusing. Greg. -----Original Message----- From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of joel Sent: Tuesday, 21 July 2009 10:00 AM To: Robinson, Greg Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] vxdisk path question/concern [SEC=UNCLASSIFIED] So I am reading you right I shouldn't care what the actual physical device is so much as what veritas is using for the name when it sees the devices in issuing "vxdisk list". If that is the case option 5 didn't work since the partition table wasn't there for the replacement (physcial sde, veritas sdf) so I went ahead and made the table. I am guessing now I will need to initialize the disk for veritas to see with option 1 on again (physcial sde, veritas sdf). I will then be able to use option 5 to add bad in the disk and I should then be able to see it working with "vxtask list" which by the way right now it's showing: TASKID PTID TYPE/STATE PCT PROGRESS 162 PARENT/R 13.56% 59/8(2) VXRECOVER Gets confusing not to care about the actual physical device names and only about the veritas names. ~joel Robinson, Greg wrote: > UNCLASSIFIED > > Hi Joel, > > The beauty of veritas is that it does not care about the SCSI disk names > to make the disk group, and, over time, I have learned to let them go as > well. > > What we need to concentrate on is the disk media names. The names in > the DISK column below. So, according to vxdisk list output, silo2dg05 > has died/been removed, and needs to be replaced. The replacement disk > will be sdf (since it doesn't have a disk media name - yet) > > You should be able to use option 5 to do that. If you really want to > disk media names to match the SCSI disk names, you can use vxedit to > rename them, but it doesn't really matter. > > Greg. > > -----Original Message----- > From: joel [mailto:j...@saldino.net] > Sent: Tuesday, 21 July 2009 4:24 AM > To: Robinson, Greg > Cc: veritas-vx@mailman.eng.auburn.edu > Subject: Re: [Veritas-vx] vxdisk path question/concern > [SEC=UNCLASSIFIED] > > The problem is sde is the new drive and sdf is one that was already on > the system. They seemed to have switched their paths somehow and I am > not sure how to get around that. So right now sdf is being seen as sde > in the list option. Not sure how they got into this particular state > google searches haven't turned up anything relative. > > ~joel > > > Robinson, Greg wrote: > >> UNCLASSIFIED >> >> Hi Joel, >> >> I believe you can run vxdiskadm, option 5 Replace a failed or removed >> disk. >> The failed disk is sde and the replacement disk is sdf. It been so >> long since I've had to use that option, but I think it might also let >> you initalise the disk in that same option. Otherwise, option 1 to >> init a disk. >> >> Hope this helps, >> >> Greg. >> >> -----Original Message----- >> From: veritas-vx-boun...@mailman.eng.auburn.edu >> [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of joel >> Sent: Saturday, 18 July 2009 10:57 AM >> To: veritas-vx@mailman.eng.auburn.edu >> Subject: [Veritas-vx] vxdisk path question/concern >> >> So I had an issue the other night where a disk was bad and replaced. >> Not sure why this happened but for some reason it seemed that all the >> drives on my array dropped off the scsi bus thus taking down the >> entire thing and locking up the box. On reboot everything was lost as >> > > >> far as the disk groups but a co-worker was able to recover. The drive >> > > >> in question that was bad was sde in a goup of 16 disks. The new drive >> > > >> is installed but for some reason the path is all wonky now. >> >> [r...@p02cd01 ~]# vxdisk list >> DEVICE TYPE DISK GROUP STATUS >> cciss/c0d0 auto:none - - online invalid >> sda auto:cdsdisk silo2dg01 silo2dg online nohotuse >> sdb auto:cdsdisk silo2dg02 silo2dg online nohotuse >> sdc auto:cdsdisk silo2dg03 silo2dg online nohotuse >> sdd auto:cdsdisk silo2dg04 silo2dg online nohotuse >> sde auto:cdsdisk silo2dg06 silo2dg online nohotuse >> sdf auto - - error >> sdg auto:cdsdisk silo2dg07 silo2dg online nohotuse >> sdh auto:cdsdisk silo2dg08 silo2dg online nohotuse >> sdi auto:cdsdisk silo2dg09 silo2dg online nohotuse >> sdj auto:cdsdisk silo2dg10 silo2dg online nohotuse >> sdk auto:cdsdisk silo2dg11 silo2dg online nohotuse >> sdl auto:cdsdisk silo2dg12 silo2dg online nohotuse >> sdm auto:cdsdisk silo2dg13 silo2dg online nohotuse >> sdn auto:cdsdisk silo2dg14 silo2dg online nohotuse >> sdo auto:cdsdisk silo2dg15 silo2dg online nohotuse >> sdp auto:cdsdisk silo2dg16 silo2dg online nohotuse >> - - silo2dg05 silo2dg removed nohotuse >> was:sde >> >> [r...@p02cd01 ~]# vxdisk path >> SUBPATH DANAME DMNAME >> GROUP STATE >> cciss/c0d0 cciss/c0d0 - >> - ENABLED >> sda sda silo2dg01 >> silo2dg ENABLED >> sdb sdb silo2dg02 >> silo2dg ENABLED >> sdc sdc silo2dg03 >> silo2dg ENABLED >> sdd sdd silo2dg04 >> silo2dg ENABLED >> sdf sde silo2dg06 >> silo2dg ENABLED >> sde sdf - >> - ENABLED >> sdg sdg silo2dg07 >> silo2dg ENABLED >> sdh sdh silo2dg08 >> silo2dg ENABLED >> sdi sdi silo2dg09 >> silo2dg ENABLED >> sdj sdj silo2dg10 >> silo2dg ENABLED >> sdk sdk silo2dg11 >> silo2dg ENABLED >> sdl sdl silo2dg12 >> silo2dg ENABLED >> sdm sdm silo2dg13 >> silo2dg ENABLED >> sdn sdn silo2dg14 >> silo2dg ENABLED >> sdo sdo silo2dg15 >> silo2dg ENABLED >> sdp sdp silo2dg16 >> silo2dg ENABLED >> >> [r...@p02cd01 ~]# vxdisk list sdf >> Device: sdf >> devicetag: sdf >> type: auto >> flags: online error private autoconfig >> errno: Disk is not usable >> Multipathing information: >> numpaths: 1 >> sde state=enabled >> >> [r...@p02cd01 ~]# vxdisk list sde >> Device: sde >> devicetag: sde >> type: auto >> hostid: opsdev1.internal.piczo.com >> disk: name=silo2dg06 id=1219276096.30.opsdev1.internal.piczo.com >> group: name=silo2dg id=1219276137.52.opsdev1.internal.piczo.com >> info: format=cdsdisk,privoffset=256,pubslice=3,privslice=3 >> flags: online ready private autoconfig nohotuse autoimport >> > imported > >> pubpaths: block=/dev/vx/dmp/sde3 char=/dev/vx/rdmp/sde3 >> version: 3.1 >> iosize: min=512 (bytes) max=65535 (blocks) >> public: slice=3 offset=2304 len=143366528 disk_offset=0 >> private: slice=3 offset=256 len=2048 disk_offset=0 >> update: time=1247816427 seqno=0.28 >> ssb: actual_seqno=0.0 >> headers: 0 240 >> configs: count=1 len=1280 >> logs: count=1 len=192 >> Defined regions: >> config priv 000048-000239[000192]: copy=01 offset=000000 enabled >> config priv 000256-001343[001088]: copy=01 offset=000192 enabled >> log priv 001344-001535[000192]: copy=01 offset=000000 enabled >> lockrgn priv 001536-001679[000144]: part=00 offset=000000 >> Multipathing information: >> numpaths: 1 >> sdf state=enabled >> >> Anyone have any ideas on how to approach this situation? >> >> Thanks >> >> ~joel >> _______________________________________________ >> Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu >> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx >> >> IMPORTANT: This email remains the property of the Australian Defence >> Organisation and is subject to the jurisdiction of section 70 of the >> Crimes Act 1914. If you have received this email in error, you are >> requested to contact the sender and delete the email. >> >> > > IMPORTANT: This email remains the property of the Australian Defence > Organisation and is subject to the jurisdiction of section 70 of the > Crimes Act 1914. If you have received this email in error, you are > requested to contact the sender and delete the email. > _______________________________________________ > Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx > _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
