Re: Solaris devices
Great thankyou for your response Ended up Cd /dev/rmt ls mt -f /dev/rmt/3stc status Had someone mounting the tape in a drive manually and went through all devices until we found the right ones, we got there in the end. Regards Mark -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Markus Engelhard Sent: Friday, 11 November 2005 4:39 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Solaris devices Hi Mark, try /opt/IBMtape/tapelist -l if you have multiple libraries, you can sort them out with /usr/lpp/Atape/samples >mtlib -l /dev/smcX -qD -f /dev/rmtX (substitute the X) This will give you a martrix to keep track of the devices have fun, Markus -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen außer für den Fall von Vorsatz oder grober Fahrlässigkeit die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mails aus. Jede von der Bank versendete E-Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Bank ausgelegt werden. __ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail or of parts hereof is strictly forbidden. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment of this message. We accept no liability for loss or damage caused by software viruses except in case of gross negligence or willful behaviour. Any e-mail messages from the Bank are sent in good faith, but shall not be binding or construed as constituting any kind of obligation on the part of the Bank.
Re: LTO drive cleaning in a 3583...
LTO "drive" cleaning is two phase: self head cleaning; and, if thereafter warranted, cleaning tape utilization. Self cleaning employs a brush to dislodge micro contaminants from the head. Being an open standard, LTO affords participating vendors full flexibility in designing internal cleaning mechanisms. According to interesting whitepaper http://www.overlandstorage.com/whitepapers/ Super_Drive_wp.pdf , IBM's drive performs a single swipe across the head as a tape is loaded and unloaded, where the brush is attached to an arm involved in the tape load/unload process. Other vendors employ a more vigorous and allegedly more thorough self cleaning process, as described in that paper and in the more detailed paper http:// www.overlandstorage.com/whitepapers/LTO_Cleaning_wp.pdf . Incorporating "canyons" into the head design greatly helps trap and isolate debris. (Standard caveat: vendor designs are subject to change.) As a trained mechanical engineer, I'd really like to know where all the removed debris goes over time. Some of it is certainly going to cling to the brush (especially, stringy dust particles); and most of it is going to either fall to some area below the brush or be propelled to various parts of the drive via the brushing action. Whereas tape drives are open to the atmosphere anyway, the detached particles are of little additional concern. The stuff which accumulates on the brush is what would concern me, as it tends to re- contaminate the head and possibly abrade it. The cumulative customer experience with LTO certainly seems to demonstrate, however, that it is extremely effective at dealing with contaminants such that the head-tape interface remains highly reliable. Richard Sims
Experience wanted with Netapp FAS960 and AIX
I just inherited a client that uses a Netapp FAS960 fibre attached to an AIX TSM server for the DB/LOG and stgpool space. Using the "sanlun show lun" command I see that there are 4 paths listed to each LUN going over FCS2 and FCS23. I also appears that the multi-pathing software was not installed. Looking at the hdisk's assigned to my VG (lsvg -p) shows that the hdisks defined to the VG's are evenly split across the FCS2/3 adapters. When I run nmon I only see traffic going down FCS3 and the activity I see on the hdisks are not the ones that are defined to the VG. Unfortunately Netapp doesn't allow you very much access to their support site unless you are a customer and the doc's I've been able to read aren't very helpful. I'm just curious if the NetappLUN drive is somehow redirecting the I/O down a "primary" path. I read in the SANPath gude that each path is either primary or seconday. I'm trying to find out if the multipathing software was licensed and just not installed, but what I'm seeing is very confusing. Anyone out there with some experience with Netapp's and AIX care to share some insight?? Bill Boyer "Growing old is mandatory, growing up is optional" - ??
Re: Experience wanted with Netapp FAS960 and AIX
On Saturday 12 November 2005 15:47, William Boyer wrote: > I just inherited a client that uses a Netapp FAS960 fibre attached to an > AIX TSM server for the DB/LOG and stgpool space. Using the "sanlun show > lun" command I see that there are 4 paths listed to each LUN going over > FCS2 and FCS23. I also appears that the multi-pathing software was not > installed. Looking at the hdisk's assigned to my VG (lsvg -p) shows that > the hdisks defined to the VG's are evenly split across the FCS2/3 adapters. > When I run nmon I only see traffic going down FCS3 and the activity I see > on the hdisks are not the ones that are defined to the VG. > > Unfortunately Netapp doesn't allow you very much access to their support > site unless you are a customer and the doc's I've been able to read aren't > very helpful. I'm just curious if the NetappLUN drive is somehow > redirecting the I/O down a "primary" path. I read in the SANPath gude that > each path is either primary or seconday. > > I'm trying to find out if the multipathing software was licensed and just > not installed, but what I'm seeing is very confusing. > > Anyone out there with some experience with Netapp's and AIX care to share > some insight?? No, but it it possible that you have multipath software and that's working. Sometimes there is a primary and a backup path. So when the primary goes down, the backup path takes over. You only see I/O on 1 path. Sometimes there is a load balancing between all available paths. So you see I/O accross all available paths. Can you post the output of lsdev -Cc disk ? Stef
