I upgraded from 3.4 since occasionally the taper got stuck i.e. stopped
working and needed a kill to finish processing. Release notes said 'fix
taper hang' so it seemed to be that problem that was solved.

Not so

ps shown both driver and taper sleeping on poll, killing the taper at
least finished the dump (in degraded mode)

The main log file relevant part seems to be this:

driver: finished-cmd time 8499.987 chunker0 chunked sapb1:"c:/SAP_DOC"
driver: send-cmd time 8499.987 to chunker0: QUIT
driver: to write host sapb1 disk "c:/SAP_DOC" date 20170706210004 on storage 
VTAPE-STORAGE
driver: state time 40773.144 free kps: 80080000 space: 177000219 taper: writing 
idle-dumpers: 10 qlen tapeq taper0: 4:0 runq: 0 directq: 0 roomq: 0 wakeup: 0 
driver-idle: no-dumpers
driver: interface-state time 40773.144 if eth0: free 80000000 if default: free 
80000
driver: hdisk-state time 40773.144 hdisk 0: free 177000219 dumpers 0
driver: result time 40773.144 from taper0: (eof)
driver: taper failed ryoko /data/svn with tape error: BOGUS
driver: taper will retry ryoko /data/svn
driver: requeue write time 40773.144 ryoko /data/svn 20170706210004 
VTAPE-STORAGE
driver: send-cmd time 40773.144 to taper0: FILE-WRITE worker0-0 00-00097 
/var/amanda/holding/DailySet/20170706210004/ryoko._data_svn.0 ryoko /data/svn 0 
20170706210004 "" "" "" 1 8589934592 "" "" "" 14901630
writing taper command 'FILE-WRITE worker0-0 00-00097 
/var/amanda/holding/DailySet/20170706210004/ryoko._data_svn.0 ryoko /data/svn 0 
20170706210004 "" "" "" 1 8589934592 "" "" "" 14901630
' failed: Broken pipe
driver: state time 40773.144 free kps: 80080000 space: 177000219 taper: writing 
idle-dumpers: 10 qlen tapeq taper0: 4:0 runq: 0 directq: 0 roomq: 0 wakeup: 0 
driver-idle: no-dumpers
driver: interface-state time 40773.144 if eth0: free 80000000 if default: free 
80000
driver: hdisk-state time 40773.144 hdisk 0: free 177000219 dumpers 0
dump of driver schedule before start degraded mode:
--------
--------
dump of driver schedule after start degraded mode:
--------

the (eof) is probably due to the kill, the BOGUS is due to the eof and
the broken pipe is due to the taper no longer existing.

The last words of taper are these:

Thu Jul 06 22:06:29.711350201 2017: pid 1348: thd-0x2420800: taper: 
Amanda::Taper::Scribe preparing to write, part size 8589934592, using LEOM 
(falling back to holding disk as cache) (splitter)  (LEOM supported)
Thu Jul 06 22:06:29.711521673 2017: pid 1348: thd-0x2420800: taper: Starting 
<Xfer@0x2956410 (<XferSourceHolding@0x27414f0> -> 
<XferDestTaperSplitter@0x2742330>)>
Thu Jul 06 22:06:29.711540075 2017: pid 1348: thd-0x2420800: taper: Final 
linkage: <XferSourceHolding@0x27414f0> -(MEM_RING)-> 
<XferDestTaperSplitter@0x2742330>
Thu Jul 06 22:06:29.711866437 2017: pid 1348: thd-0x2420800: taper: header 
native_crc: 81fb47b2:15259269120
Thu Jul 06 22:06:29.711880523 2017: pid 1348: thd-0x2420800: taper: header 
client_crc: db2f43af:14822266889
Thu Jul 06 22:06:29.711888251 2017: pid 1348: thd-0x2420800: taper: header 
server_crc: db2f43af:14822266889
Thu Jul 06 22:06:29.711955784 2017: pid 1348: thd-0x2420800: taper: 
start_recovery called
Thu Jul 06 22:06:29.713768937 2017: pid 1348: thd-0x2928f20: taper: Building 
type SPLIT_FILE header of 32768-32768 bytes with name='ryoko' disk='/data/svn' 
dumplevel=0 and blocksize=32768

I'm using a vtape configuration and in the slot there is indeed no
_data_svn file, it didn't even made the header.

I have saved all the server log files for the run and can obviously
supply all the configuration, too.

Is this a known issue and/or how can I troubleshoot it?

Thanks in advance

-- 
Lorenzo Marcantonio

Attachment: signature.asc
Description: PGP signature

Reply via email to