Unsolved
This post is more than 5 years old
45 Posts
0
1572
Some Physical and Virtual Tapes marked full pre-maturely after upgradation to Networker 8.0
Hi All
Would like your inputs on the situation which i have been facing for the past three weeks or so.
We migrated our NSR server to a new physical Server and Upgraded it from 7.6 to 8.0 with OS Win 2008 R2.
Since my upgradation i had seen some of the tapes marked prematurely full, these tapes were both Virtual and Physical.
I then checked and corrected the SCSI resets the logs indicated to (fixed my access groups on the DD VTL and made certain changes to the Zoning of the Physical Library that helped), and the issue seemed resolved.
But off late I have exprienced some tapes again, being marked full, and i suspect it has to do something with the Block sizes.
Below are the logs for a tape that was marked full at 138 GB's as opposed to its native capacity of 1.5 TB (LTO5)
Unable to render the following message: 38758 1395686206 0 0 0 7232 4064 0 hobkp1.fgb.ae nsrd NSR info 9 %s %s: %s 3 0 5 media 0 7 warning 0 69 \\.\Tape2147483646 writing: The media in the drive may have changed.
Unable to render the following message: 38758 1395686206 0 0 0 7232 4064 0 hobkp1.fgb.ae nsrd NSR info 9 %s %s: %s 3 0 5 media 0 7 warning 0 69 \\.\Tape2147483646 writing: The media in the drive may have changed.
71193 3/24/2014 10:36:46 PM 0 0 0 7232 4064 0 hobkp1.fgb.ae nsrd NSR info Media Notice: LTO Ultrium-5 tape FGB542 on \\.\Tape2147483646 is full
71193 3/24/2014 10:36:46 PM 0 0 0 7232 4064 0 hobkp1.fgb.ae nsrd NSR info Media Info: WORM capable for device \\.\Tape2147483646 has been set
71193 3/24/2014 10:36:48 PM 0 0 0 7232 4064 0 hobkp1.fgb.ae nsrd NSR info Media Notice: Volume "FGB542" on device "\\.\Tape2147483646": Block size is 32768 bytes not 262144 bytes. Verify the device configuration. Tape positioning by record is disabled.
Kindly advise on the issue as we are finding it difficult to isolate the problem.
nmc2
268 Posts
0
March 28th, 2014 08:00
In case of physical tapes, upgrading the drive firmware and drivers can help to fix this issue to an extent.
Did you consult DD support on this issue?
If issue persists, i think its better to open a Service Request.
Regards,
Prajith
ble1
2 Intern
2 Intern
•
14.3K Posts
1
March 28th, 2014 09:00
As you changed OS, I would double check drivers first. Make sure you use driver version which is known to be ok (sorry, I do not use LTO5 on Windows so I can't provide version here). Just out of curiosity, if you change volume state to appendable (which you can do via CLI or GUI) and you try to write on it - do you get tape full right away or you can still write some data?
Further, are there any patterns in time when this error occurs? Are drives zoned only to hosts using it? Do you use IO blade?
DataProtectxr
45 Posts
0
March 28th, 2014 09:00
Yea, Hrvoje, these logs are for PTL
Kindly advise about this issue.
ble1
2 Intern
2 Intern
•
14.3K Posts
0
March 28th, 2014 09:00
I assume that is physical tape library (for VTL this depends as you can define size of volume).
DataProtectxr
45 Posts
0
March 29th, 2014 07:00
Hi Hrvoje,
The drives were working fine after a month of the Upgrade so, i believe the drivers are fine.
As i change the state to appendable and try to write the volume is marked full immediately.
Not exactly a pattern to this problem , but yes it happens between 10.30 PM to 11.30 PM
We do not use IO blade , and yes drives are zoned from switch end to a server that is not particluarly using it at this point in time, do youi suspect this as a potential problem ? and Yes, this drive acts as a Dynamic Storage Node to another host as well.
ble1
2 Intern
2 Intern
•
14.3K Posts
1
March 29th, 2014 10:00
You might be getting scsi bus resets which I do not think would cause what you see, but who knows. Obviously end-of-tape marker seems to be found where it is reported to be and you can't pass by it at all. Now few questions:
- does this happens on all drives
- if not does it happen on drives on same HBA/switch
- are your tapes used outside 10:30-11:30 window? Can you move 10:30-11:30 activity to some other slot to see if error follows under same pattern of consequences?
- I noticed you use TapeXXXXXXXXXXX format - is this Windows persistent binding format or IBM tape drives?