Hi, On 5/23/2007 12:16 PM, Andreas Helmcke wrote: > On 23.05.2007 10:28, Christoph Buchli wrote: >> Now the empirical things: >> - I have to _stop_ bacula to do certain test, otherwise "mtx", "tar" etc >> always >> tell me - as an error - that the device is busy. > > Sure. While the sd is running it normally keeps the tape devices open.
Right... we should have mentioned that previously :-) >> - The device could be working. I attached some command-outputs that are my >> reasons to believe so: ... which looks perfectly Ok. > Tape block size should not be fixed. It should be set to 0 (variable > block size). Right. Or, if that's not possible for whatever reason, it should be set to a multiple of the drives native block size (which I'm not sure of, now, but usually a block size of 32, 64, or 128k should work. I would have to look that up...) >> Soft error count since last status=0 >> General status bits on (41010000): >> BOT ONLINE IM_REP_EN > >> # tar -cf /dev/nst0 /tmp/ >> tar: Removing leading `/' from member names >> (This works, I guess.) Yes. This is tars way of ensuring you can restore to different locations, even when giving absolute path names. >> Well now, the less funny part: >> >> # mtx -f /dev/sg3 status >> mtx: Request Sense: 70 00 02 00 00 00 00 1E 00 00 00 00 04 03 00 00 00 00 00 >> 00 >> READ ELEMENT STATUS Command Failed >> > > That *is* strange. As Arno already wrote this message is very unusual > for mtx. At least, i have never seen something alike. > > Please check which version of mtx you have (mtx --version). > Maybe using a new version could help. > > Take a look at: > http://sourceforge.net/projects/mtx > > (I am using version 1.3.10) If I recall correctly, mtx is now maintained by Robert Nelson, who took that project over when involved with Bacula. I found him to be quite helpful when you can give him the information he needs to debug a problem. >> # /usr/pack/bacula_mysql-2.0.3-rp/amd64-debian-linux3.1/scripts/mtx-changer >> /dev/sg3 load 1 /dev/nst0 0 >> mtx: Request Sense: 70 00 02 00 00 00 00 1E 00 00 00 00 04 03 00 00 00 00 00 >> 00 >> READ ELEMENT STATUS Command Failed > > As long as the mtx status command does not work there is no need to > bother with mtx-changer because mtx-changer just depends on mtx working > correctly. > >> # mt -f /dev/sg3 eject >> /dev/sg3: Operation not permitted >> > That's normal. A changer does not know how to "eject" a tape. > Eject is used for tape drives. And even there, I think that it is not > used with LTO drives. For your drive it should be sufficient to use > mt -f /dev/nst0 offline Just to make sure, I usually use rewoffline, which should not really be necessary with todays drives, but it doesn't hurt, too... > BTW _after_ you have got mtx status working you should check whether > your changer needs the drive to be offline before it could do an unload. > If it does, you have to change the mtx-changer script or you'll get > obscure errors when doing an unmount. The necessary modification is simple, by the way. >> # dmesg | tail >> [168322.441562] NFSD: starting 90-second grace period >> [1188266.284746] st0: Write not multiple of tape block size. >> [1188301.160942] st0: Write not multiple of tape block size. >> [1189175.640945] st0: Write not multiple of tape block size. >> [1189249.930203] st0: Write not multiple of tape block size. >> [1206329.081616] st0: Write not multiple of tape block size. >> [1206335.525053] st0: Write not multiple of tape block size. >> [1206359.269428] st0: Write not multiple of tape block size. >> [1207514.104233] st0: Write not multiple of tape block size. >> [1791080.401660] st0: Write not multiple of tape block size. >> > > This might be related to the lines: > >>> Minimum block size = 1024 >>> Maximum blocksize = 1024 Yes I think so. > in your bacula-sd config. > And/or the fact that your tape and/or drive set to blocksize 512. Hmm... probably not, because 1024 *is* a multiple of 512 :-) > But I am relative sure, this doesn't stop mtx status from working. If it would that would be news to me, too. By the way - I'm quite sure that a Superloader3 can work with Bacula, but I have no configuration or device setup details available. I could ask, perhaps, but first you should check your mtx. Perhaps you could even try another distribution as a live system. Arno > > Andreas > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
