I'm having a problem whereby the mtx command is opening the
changer device and getting back the contents of the tape. I
repeatedly reproduce this if I do the following:

1. Perform some operation, such as a backup
2. Schedule a job to verify the last catalog backup
3. Schedule a job to perform some other verification job that
uses a different tape
4. Complete the catalog backup verification
5. Bacula calls mtx-changer, which calls mtx, to switch to the
needed tape.
6. mtx-changer fails on the 'loaded' command with 
mtx: Request Sense: 70
00 05 00 00 00 00 0A 00 00 00 00 21 01 00 C0 00 00 00 00
READ ELEMENT STATUS Command Failed
7. mtx-changer fails on the load command as there is already a
tape loaded.
8. Bacula yells for help.


When I wrap mtx with strace, I see the following:

1793  open("/dev/sg4", O_RDWR)          = 3
1793  write(3, 
"0\0\0\0\240\34M\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2702 
   \0M\34|\0\0", 48) = 48
1793  read(3, 
"\240\34M\0\240\34M\0\0\0\0\0\0\0\0\0\2\0\2\0p\0\5\0\0\0\0\n\0\0\0\0!\1\0\300\23
 
Wx0\361\253r\375\3\340\332\262\313T\366j\212\200\323E\252;\333i\t\372\5#a\277\371\272\f{\372\202\340(0U\0\35\366u\"\30l\326k\314\3zj\231\vzeX\250\fz\265Y\27\240~\315\204\3W\205\277\22\373\225|\4M\245\223}/[\232\32\n\350\235\26\213\353\4\177\255A\333\370^\275
 
zGn\35!F\32\22!g<\3\2{\37\346WS\277\24\23\ts\265\201:\305\273\5\0200\343\177\313<\262px\3515D\330x\351s\277\32!%ip\205\201V\224\3227(\352\3\2155\300\242\223
 
\307\342\270n\302C\261A\315\205I\337\374sQ\272\343s\325\230\215\262%p4\372\273G\324Z+\242\307\250_\261]\224\307\207S\346O\363\27\25\354\"\271\375\272\337\304\242A\7\312\276\30\305\16\335r$\r\235_\315\226\345\350\300\354\305gl\34\16`\261\302\356P\377kT90\376m#8\f\224:\2612\311p\253\10\202\375\305\366\\u\270\2109\360\233\23\264\21\345\367\322xX\37\350\344\350\2572\370\32\244\272\37)Fu\217,\5f[\357\244}\345\350m>\3J\254\357\301<\236\4\277Zu}R}\26B\177A\257gb\307\177\"\274\266\304\276\267\202\7\243\207\277\26\333*g\220\23\335\253K\31\363\2\257\303\273\3347S\341\300\272\350/iA\33\354
 
m\330\\v\320<l./H\23A\324\351\260\4\3439,?W\24\310\27\0360\324\23\22\376j$!\346\266\t\271\f\246\10\17X\370\26\300\316\217\357{\333\263\27\36\213)<3\275\210&<?-\5\273awx\200\21\375\316\347\0\"\200\335\177N\\\3\250\31\276\316\25\317\7Z\17\202\r\'[EMAIL
 
PROTECTED]:_,\331\34\31S\210\274*7\3\3436W\274?\10\0\361\244\204`\331-\327\303\217\n\263\370\322\26\202$}\362D\272\361f5\305oW8\320m\224\246T\251\263{A\317(\200O\321\'\252\361\223\350\342b\217(\200\207\240\222L/T\252\ts*\266\233\240\212\320\361Y\270\215\330\203\30\350\225\270\345`G\264%\227v\201x|Nx\251n\277M\370\360\200\301\36l\251nW\223\311i\247w-\203\323b\302\316\25\233+\2577\217A\345\371S\30\225\310\1\263\323b\354\323\274
 \177\330\234\315\356\201\351j\342\226\225i\'|\320\n\202\221\343a3\346"..., 
5053600) = 5053600
1793  write(3, 
"0\0\0\0\240\34M\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\270\"
    \0M\34|\0\0", 48) = 48
1793  read(3, 
"\240\34M\0\240\34M\0\0\0\0\0\0\0\0\0\2\0\2\0p\0\5\0\0\0\0\n\0\0\0\0!\1\0\300 B 
A A A B/ IAA I BENL/u BDBndZ BENL/u A A 
C\',\'yktl64+/Gw+w3W+Nux/IZC\'),(35218579,6473522,58,745134,65118,0,\'T URYBY 
IGk B A A A aL6 IAA Dg BENL/u BDBncy BENL/u A A 
C\',\'qFpjFzhMJm+wGk/3SF/5mB\'),(35218580,6473523,58,745134,65112,0,\'T URYBZ 
IGk B A A A y5Q IAA Gg BENL/u BDBncx BENL/u A A 
C\',\'c1+Gy4+CMn+eEH+mmR/0OA\'),(35218581,6473524,58,745134,65110,0,\'T URYBb 
IGk B A A A X IAA I BENL/u BDBncy BENL/u A A 
C\',\'48/muQ5rai+2E5gC37dgEA\'),(35218582,6473525,58,745134,65108,0,\'T URYBc 
IGk B A A A Ee IAA I BENL/u BDBndZ BENL/u A A 
C\',\'U8+sih/oez/mw+lagCZlDA\'),(35218575,6473518,58,745133,65109,0,\'T URcBb 
IGk B A A A 2 IAA I BENL/u BDBncy BENL/u A A 
C\',\'iW+Yq9sB+89Xq7/FR7/GED\'),(35218574,6473517,58,745132,2,0,\'T HKIF6 EHt D 
A A A BAA IAA I BENMOf BEKu3h BENMOf A A 
C\',\'0\'),(35218573,6473516,58,745132,65115,0,\'T URUCL IGk B A A A lI IAA I 
BENL/u BDBndP BENL/u A A 
C\',\'t9+gZ+RVRC/WN3/mMRhSwD\'),(35218572,6473515,58,745132,65107,0,\'T URUCK 
IGk B A A A 2 IAA I BENL/u B"..., 5053600) = 5053600
1793  write(2, "mtx: Request Sense: 70", 22) = 22
1793  write(2, " 00", 3)                = 3
1793  write(2, " 05", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 0A", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 21", 3)                = 3
1793  write(2, " 01", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " C0", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, " 00", 3)                = 3
1793  write(2, "\n", 1)                 = 1
1793  write(2, "READ ELEMENT STATUS Command Failed\n", 35) = -1 EPIPE (Broken 
pipe)


Now, it looks to me like mtx is opening the changer device
/dev/sg4 (which is the correct device), reading, and getting a
series of insert statements for the File table for MySQL instead
of the device status. Running 'mount' at the bconsole prompt is
enough to get it to retry the loaded / unload / load cycle for
the next tape and continue. 

All of the tapes are barcoded, and the Autochanger is in random
mode.

This is on a ADIC Scalar24 w/LTO-3 drives, using a fiberchannel connection.
mtx version 1.2.17rel
Red Hat Enterprise Linux ES release 4 (Nahant Update 2)
bacula-mysql-1.36.3-1 
Linux xxx 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 athlon i386 
GNU/Linux
QLogic ISP23xx FC-SCSI Host Bus Adapter driver
mysql  Ver 14.7 Distrib 4.1.12, for redhat-linux-gnu (i386) using readline 4.3

The tape system otherwise works pretty well, and normally can do a few tape
changes in a row w/o problems. However, I cannot reliably get through an entire
backup (several tapes) w/o it choking in a similiar fashion. It
occasionally chokes similiarly on other operations, but the
steps above reliably cause the failure.

All of the normal tape testing operations work. I can manually
tell it to switch tapes w/mtx-changer just fine, it seems to be
somehow involved with the reading or writing of the tape.

Any suggestions? Is there something I can put into the mtx-changer script to
clear any outstanding buffers? A 'sleep 60' at the top of
mtx-changer did not help the situation.

Thank you,
-Jason Martin
-- 
This message is PGP/MIME signed.

Attachment: pgp4fzITZJqPL.pgp
Description: PGP signature

Reply via email to