On Tuesday 11 April 2006 15:46, Jason Martin wrote:
> <resending, mailman seems to have ate the last one>
>
> 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\3
>00\23
> Wx0\361\253r\375\3\340\332\262\313T\366j\212\200\323E\252;\333i\t\372\5#a\2
>77\371\272\f{\372\202\340(0U\0\35\366u\"\30l\326k\314\3zj\231\vzeX\250\fz\26
>5Y\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\17
>7\313<\262px\3515D\330x\351s\277\32!%ip\205\201V\224\3227(\352\3\2155\300\24
>2\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\3
>37\304\242A\7\312\276\30\305\16\335r$\r\235_\315\226\345\350\300\354\305gl\3
>4\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\2
>57gb\307\177\"\274\266\304\276\267\202\7\243\207\277\26\333*g\220\23\335\253
>K\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]
>264\v$\361\5\346G\0\253N^8\236\356hnT#`\317\232J\17O\326\21\271\327D\274\266
>\236\362\224c1\304\333\263\315\227\233:_,\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\305
>oW8\320m\224\246T\251\263{A\317(\200O\321\'\252\361\223\350\342b\217(\200\20
>7\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\27
>4 \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\3
>00 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.
Or possibly it is getting data that should be written to a tape. You aren't by
any chance using "Archive device = /dev/sg4" somewhere in one of your Device
resources are you?
> 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
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
