Content preview:  Hi ADSM-L, We've been having a problem where TSM logs an 
ANR8341I
    message ("End-of-volume reached for LTO volume nnnnnn") for a volume, but
    it never actually transitions the volume from filling to full. This means
    TSM will dismount the volume, but then try to remount it elsewhere. 
Currently
    we're seeing this problem on two volumes, and it doesn't seem to be tied
   to any subset of our drives. [...]

 Content analysis details:   (0.6 points, 5.0 required)

  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.7 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 -0.0 T_RP_MATCHES_RCVD      Envelope sender domain matches handover relay
                             domain
X-Barracuda-Connect: mx.gs.washington.edu[128.208.8.134]
X-Barracuda-Start-Time: 1515433530
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://148.100.49.27:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at marist.edu
X-Barracuda-Scan-Msg-Size: 1534
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 
QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.46670
        Rule breakdown below
         pts rule name              description
        ---- ---------------------- 
--------------------------------------------------

Hi ADSM-L,

We've been having a problem where TSM logs an ANR8341I message
("End-of-volume reached for LTO volume nnnnnn") for a volume, but it never
actually transitions the volume from filling to full. This means TSM will
dismount the volume, but then try to remount it elsewhere. Currently we're
seeing this problem on two volumes, and it doesn't seem to be tied to any
subset of our drives.

We had this problem previously in November, and after opening a PMR, TSM
support suggested that it was a hardware issue of some kind (drive or
library). I've updated all of our drives to the latest firmware that we can
get from Oracle (we're running SL3000s), which is G9Q2. This seemed to
solve it for a little bit, but now we're seeing it again. I'm not seeing
any obvious errors in the activity log, ACSLS, or the library logs. The
only things I can really see are the ANR8341I messages, and the times
mounted counter go up (we have some volumes that have been mounted well
over a thousand times in less than a year because of this).

We're running TSM v7.1.8.0 on RHEL6 x86_64, with a SL3000 (ACSLS) and IBM
LTO7 drives all running firmware G9Q2.

Before I open another PMR, has anyone else seen this problem? I suspect the
next step will be server tracing, which is likely to be a big performance
hit.

Thanks!

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine