Re: curious behavior
I just rechecked things with the comments from the list. It seems the current access level of the tape didn't have any bearing on the situation. Right now I have a q mo showing one tape as R/W and the other as R/O. The q vol f=d is telling me that both tapes are Read/Write. tsm: BACKUP1q pr Process Process Description Status Number - 616 Space ReclamationOffsite Volume(s) (storage pool NEWCOPYPOOL), Moved Files: 5868, Moved Bytes: 22,303,511,754, Unreadable Files: 543, Unreadable Bytes: 0. Current Physical File (bytes): 11,347,126,815 Current input volume: 03L2. Current output volume: 93L2. tsm: BACKUP1q mo ANR8330I LTO volume 03L2 is mounted R/O in drive DRV4 (mt0.5.0.5), status: IN USE. ANR8330I LTO volume 93L2 is mounted R/W in drive DRV2 (mt0.3.0.5), status: IN USE. ANR8334I 2 matches found. tsm: BACKUP1q vol 03l2 f=d Volume Name: 03L2 Storage Pool Name: NEWTAPEPOOL Device Class Name: LTO2 Estimated Capacity (MB): 431,430.2 Scaled Capacity Applied: Pct Util: 93.8 Volume Status: Full Access: Read/Write Pct. Reclaimable Space: 6.6 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 18 Write Pass Number: 1 Approx. Date Last Written: 03/29/2005 17:13:29 Approx. Date Last Read: 04/01/2005 12:36:43 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: Volume is MVS Lanfree Capable : No Last Update by (administrator): Last Update Date/Time: 03/28/2005 21:27:17 tsm: BACKUP1q vol 93l2 f=d Volume Name: 93L2 Storage Pool Name: NEWCOPYPOOL Device Class Name: LTO2 Estimated Capacity (MB): 204,800.0 Scaled Capacity Applied: Pct Util: 10.3 Volume Status: Filling Access: Read/Write Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 1 Write Pass Number: 1 Approx. Date Last Written: 04/01/2005 12:47:32 Approx. Date Last Read: 04/01/2005 12:02:48 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: Volume is MVS Lanfree Capable : No Last Update by (administrator): Last Update Date/Time: 04/01/2005 12:01:20
Re: curious behavior
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tyree, David I just rechecked things with the comments from the list. It seems the current access level of the tape didn't have any bearing on the situation. Right now I have a q mo showing one tape as R/W and the other as R/O. The q vol f=d is telling me that both tapes are Read/Write. That is correct behavior. 03L2 is the input tape for your reclamation process; it will be mounted R/O so that nothing can be written to the source tape while it moves data to the target tape. WAD. I *have* seen instances where a source tape, which should be mounted R/O, is instead mounted R/W. I haven't tracked the issue because, quite frankly, it's not much of an issue; I am usually running down more serious problems. -- Mark Stapleton ([EMAIL PROTECTED]) IBM Certified Advanced Deployment Professional Tivoli Storage Management Solutions 2005 Office 262.521.5627
Re: curious behavior
Hi, Not that curious. The input tape for the reclaim process is mounted in the read-Only status, the output tapes is being writen to, so is mounted read/write. This is normal and has nothing to do with the access state of a volume seen by q vol. In case of a readonly volume, mounted in read/write status and also being the output volume of a process, I would begin to get worried Regards, _ Karel Bos Technical Expert level 5 Server Management - Operations Back-up en Restore Customer Unit Nuon Atos Origin Nederland B.V. Arlandaweg 98 1043 HP Amsterdam Office: +31 (0)20 Fax: +31 (0)20 Mobile: +31 (0)6.51.29.88.01 Mail: [EMAIL PROTECTED] The information in this mail is intended only for use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Access to this mail by anyone else than the addressee is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken omitted to be taken in reliance of it, is prohibited and may be unlawful. If you are not the intended recipient please contact the sender by return e-mail and destroy all copies of the original message. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tyree, David Sent: vrijdag 1 april 2005 20:01 To: ADSM-L@VM.MARIST.EDU Subject: Re: curious behavior I just rechecked things with the comments from the list. It seems the current access level of the tape didn't have any bearing on the situation. Right now I have a q mo showing one tape as R/W and the other as R/O. The q vol f=d is telling me that both tapes are Read/Write. tsm: BACKUP1q pr Process Process Description Status Number - 616 Space ReclamationOffsite Volume(s) (storage pool NEWCOPYPOOL), Moved Files: 5868, Moved Bytes: 22,303,511,754, Unreadable Files: 543, Unreadable Bytes: 0. Current Physical File (bytes): 11,347,126,815 Current input volume: 03L2. Current output volume: 93L2. tsm: BACKUP1q mo ANR8330I LTO volume 03L2 is mounted R/O in drive DRV4 (mt0.5.0.5), status: IN USE. ANR8330I LTO volume 93L2 is mounted R/W in drive DRV2 (mt0.3.0.5), status: IN USE. ANR8334I 2 matches found. tsm: BACKUP1q vol 03l2 f=d Volume Name: 03L2 Storage Pool Name: NEWTAPEPOOL Device Class Name: LTO2 Estimated Capacity (MB): 431,430.2 Scaled Capacity Applied: Pct Util: 93.8 Volume Status: Full Access: Read/Write Pct. Reclaimable Space: 6.6 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 18 Write Pass Number: 1 Approx. Date Last Written: 03/29/2005 17:13:29 Approx. Date Last Read: 04/01/2005 12:36:43 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: Volume is MVS Lanfree Capable : No Last Update by (administrator): Last Update Date/Time: 03/28/2005 21:27:17 tsm: BACKUP1q vol 93l2 f=d Volume Name: 93L2 Storage Pool Name: NEWCOPYPOOL Device Class Name: LTO2 Estimated Capacity (MB): 204,800.0 Scaled Capacity Applied: Pct Util: 10.3 Volume Status: Filling Access: Read/Write Pct. Reclaimable Space: 0.0 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 1 Write Pass Number: 1 Approx. Date Last Written: 04/01/2005 12:47:32 Approx. Date Last Read: 04/01/2005 12:02:48 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: Volume is MVS Lanfree Capable : No Last Update by (administrator): Last Update Date/Time: 04/01/2005 12:01:20
Re: curious behavior
On Apr 1, 2005, at 1:11 PM, Stapleton, Mark wrote: ...I *have* seen instances where a source tape, which should be mounted R/O, is instead mounted R/W. I haven't tracked the issue because, quite frankly, it's not much of an issue; I am usually running down more serious problems. I wonder if it's a situation where the tape had been mounted for a preceding R/W operation then, during the MOUNTRetention period, along came the next request for it, as an input volume. Richard Sims
curious behavior
(Running TSM 5.2.2 on Win2k with 4 LTO2 drives in a Powervault 136T) I've been seeing this for quite a while on our system. It's not an issue but it sure does look strange. Unless I'm missing something here, if you are running a process that is copying data from the tapepool to the copypool shouldn't the results of a Q mount show that you have a tape with R/O and another one showing R/W? I've seen this in other processes that involve multiple drives. If you do the q proc it tells you where it is reading from and where it is writing to. But if you go back and do a q mount then it doesn't match up with the info from the q proc. I know which tape is in which drive and I know that the data is actually going where I want it to but the q mount info kinda startles every once in a while. As you can see here, it looks like the q mo is telling that I'm writing to both tapes. The q proc tells me otherwise. I've done a quick series of q mounts back to back and the drives always show the same. It looks like I'm writing to both drives in this case. tsm: BACKUP1q mo ANR8330I LTO volume 26L2 is mounted R/W in drive DRV2 (mt0.3.0.5), status: IN USE. ANR8330I LTO volume 33L2 is mounted R/W in drive DRV3 (mt0.4.0.5), status: IN USE. ANR8334I 2 matches found. tsm: BACKUP1q pr Process Process Description Status Number - 582 Backup Storage Pool Primary Pool NEWTAPEPOOL, Copy Pool NEWCOPYPOOL, Files Backed Up: 2, Bytes Backed Up: 16,792,685, Unreadable Files: 0, Unreadable Bytes: 0. Current Physical File (bytes): 59,738,060,746 Current input volume: 26L2. Current output volume: 33L2. Even if I have all four drives churning away on different processes the q mo will tell me one thing and the q proc will tell me something else. It's completely random. If a drive shows up as right for one process then the next time it gets used for another process then it might show up wrong. Again, everything is actually working as it should it just looks strange. Is this a bug or a feature? Thanks... David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: curious behavior
The mount mode (R/O, R/W) should match the volume's current access, as shown by the QUERY VOLUME command with FORMAT=DETAILED. The mount mode does not correspond to the current read/write usage of the volume. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] The only dumb question is the one that goes unasked. The command line is your friend. Good enough is the enemy of excellence. ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 2005-03-31 11:19:43: (Running TSM 5.2.2 on Win2k with 4 LTO2 drives in a Powervault 136T) I've been seeing this for quite a while on our system. It's not an issue but it sure does look strange. Unless I'm missing something here, if you are running a process that is copying data from the tapepool to the copypool shouldn't the results of a Q mount show that you have a tape with R/O and another one showing R/W? I've seen this in other processes that involve multiple drives. If you do the q proc it tells you where it is reading from and where it is writing to. But if you go back and do a q mount then it doesn't match up with the info from the q proc. I know which tape is in which drive and I know that the data is actually going where I want it to but the q mount info kinda startles every once in a while. As you can see here, it looks like the q mo is telling that I'm writing to both tapes. The q proc tells me otherwise. I've done a quick series of q mounts back to back and the drives always show the same. It looks like I'm writing to both drives in this case. tsm: BACKUP1q mo ANR8330I LTO volume 26L2 is mounted R/W in drive DRV2 (mt0.3.0.5), status: IN USE. ANR8330I LTO volume 33L2 is mounted R/W in drive DRV3 (mt0.4.0.5), status: IN USE. ANR8334I 2 matches found. tsm: BACKUP1q pr Process Process Description Status Number - 582 Backup Storage Pool Primary Pool NEWTAPEPOOL, Copy Pool NEWCOPYPOOL, Files Backed Up: 2, Bytes Backed Up: 16,792,685, Unreadable Files: 0, Unreadable Bytes: 0. Current Physical File (bytes): 59,738,060,746 Current input volume: 26L2. Current output volume: 33L2. Even if I have all four drives churning away on different processes the q mo will tell me one thing and the q proc will tell me something else. It's completely random. If a drive shows up as right for one process then the next time it gets used for another process then it might show up wrong. Again, everything is actually working as it should it just looks strange. Is this a bug or a feature? Thanks... David Tyree Enterprise Backup Administrator South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: curious behavior
David I never thought I'd say this, but I don't entirely agree with Andy. From my observations, during a reclamation, COPY STGPOOL or MOVE DATA process, the source volume may be mounted R/O if its status is FULL regardless of it's access. Regards Neil Schofield Yorkshire Water Services Ltd. tsm: TSM1q vol G01081 f=d Volume Name: G01081 Storage Pool Name: LOC_TAPEPOOL_GENERAL_ARCHIVE Device Class Name: LOC_STKL5500 Estimated Capacity (MB): 79,379.7 Scaled Capacity Applied: Pct Util: 71.8 Volume Status: Full Access: Read/Write Pct. Reclaimable Space: 28.2 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 8 Write Pass Number: 1 Approx. Date Last Written: 05-01-2005 11:28:21 Approx. Date Last Read: 09-11-2004 11:43:48 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: Volume is MVS Lanfree Capable : No Last Update by (administrator): more... (ENTER to continue, 'C' to cancel) Last Update Date/Time: 09-11-2004 11:43:16 tsm: TSM1move data G01081 ANR2232W This command will move all of the data stored on volume G01081 to other volumes within the same storage pool; the data will be inaccessible to users until the operation completes. Do you wish to proceed? (Yes (Y)/No (N)) y ANS8003I Process number 3887 started. tsm: TSM1q pro Process Process Description Status Number - 3,887 Move DataVolume G01081 (storage pool LOC_TAPEPOOL_GENERAL_ARCHIVE), Target Pool LOC_TAPEPOOL_GENERAL_ARCHIVE, Moved Files: 2447, Moved Bytes: 168,867,360, Unreadable Files: 0, Unreadable Bytes: 0. Current Physical File (bytes): None Current input volume: G01081. Current output volume: G00676. tsm: TSM1q mount ... ANR8330I ECARTRIDGE volume G01081 is mounted R/O in drive TSM1_GS02STKL5500 (\\.\mt13.0.1.9), status: IN USE. ANR8330I ECARTRIDGE volume G00676 is mounted R/W in drive TSM1_GS02STKL5500 (\\.\mt1.0.1.6), status: IN USE. ... tsm: TSM1 Visit cool-fuel.com to see our fun, interactive website for children YORKSHIRE WATER - WINNER OF THE UTILITY OF THE YEAR AWARD The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682
Re: curious behavior
You are correct, I verified this myself with a MOVE DATA against a full read/write volume. QUERY MOUNT shows it mounted as R/O. Sorry for passing on misinformation. I'm gonna go back to the server guys and ask for their clarification. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] The only dumb question is the one that goes unasked. The command line is your friend. Good enough is the enemy of excellence. ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 2005-03-31 14:34:45: David I never thought I'd say this, but I don't entirely agree with Andy. From my observations, during a reclamation, COPY STGPOOL or MOVE DATA process, the source volume may be mounted R/O if its status is FULL regardless of it's access. Regards Neil Schofield Yorkshire Water Services Ltd. tsm: TSM1q vol G01081 f=d Volume Name: G01081 Storage Pool Name: LOC_TAPEPOOL_GENERAL_ARCHIVE Device Class Name: LOC_STKL5500 Estimated Capacity (MB): 79,379.7 Scaled Capacity Applied: Pct Util: 71.8 Volume Status: Full Access: Read/Write Pct. Reclaimable Space: 28.2 Scratch Volume?: Yes In Error State?: No Number of Writable Sides: 1 Number of Times Mounted: 8 Write Pass Number: 1 Approx. Date Last Written: 05-01-2005 11:28:21 Approx. Date Last Read: 09-11-2004 11:43:48 Date Became Pending: Number of Write Errors: 0 Number of Read Errors: 0 Volume Location: Volume is MVS Lanfree Capable : No Last Update by (administrator): more... (ENTER to continue, 'C' to cancel) Last Update Date/Time: 09-11-2004 11:43:16 tsm: TSM1move data G01081 ANR2232W This command will move all of the data stored on volume G01081 to other volumes within the same storage pool; the data will be inaccessible to users until the operation completes. Do you wish to proceed? (Yes (Y)/No (N)) y ANS8003I Process number 3887 started. tsm: TSM1q pro Process Process Description Status Number - 3,887 Move DataVolume G01081 (storage pool LOC_TAPEPOOL_GENERAL_ARCHIVE), Target Pool LOC_TAPEPOOL_GENERAL_ARCHIVE, Moved Files: 2447, Moved Bytes: 168,867,360, Unreadable Files: 0, Unreadable Bytes: 0. Current Physical File (bytes): None Current input volume: G01081. Current output volume: G00676. tsm: TSM1q mount ... ANR8330I ECARTRIDGE volume G01081 is mounted R/O in drive TSM1_GS02STKL5500 (\\.\mt13.0.1.9), status: IN USE. ANR8330I ECARTRIDGE volume G00676 is mounted R/W in drive TSM1_GS02STKL5500 (\\.\mt1.0.1.6), status: IN USE. ... tsm: TSM1 Visit cool-fuel.com to see our fun, interactive website for children YORKSHIRE WATER - WINNER OF THE UTILITY OF THE YEAR AWARD The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682
