*********** REPLY SEPARATOR ***********
On 22/11/2005 at 12:28 PM Kern Sibbald wrote: >On Tuesday 22 November 2005 12:05, __DireWolf wrote: >> *********** REPLY SEPARATOR *********** >> >> On 22/11/2005 at 11:33 AM Kern Sibbald wrote: >> >Hello, >> > >> >On Tuesday 22 November 2005 10:11, __DireWolf wrote: >> >> >From reading a few of the archives, getting an IDE Tape drive working >> >> > in bacula is a real nightmare. >> >> >> >> Welcome to my Nightmare ;) >> > >> >Yea, I have been through this before. It wasn't easy. Good luck ... >> > >> >> Sorry if this looks like too much info but I always see flames about >not >> >> including enough detail to help troubleshoot. >> > >> >Hey, didn't anyone tell you that we don't flame on this list? Well, >maybe >> >once or twice in 5 years :-) >> > >> >I'm pleased to see you following the suggestions. It really helps. >> > >> >See the end of your email for a suggestion ... >> > >> >> Anyway, I've started off at the "Testing Your Tape Drive With Bacula" >> > >> >page >> > >> >> here: http://bacula.org/dev-manual/Testing_Your_Tape_Drive.html >> >> >> >> I first looked for my drive >> >> >> >> =============================================== >> >> [EMAIL PROTECTED] ~]# dmesg | grep TAPE >> >> hdc: Seagate STT8000A, ATAPI TAPE drive >> >> =============================================== >> >> >> >> Then loaded the ide-scsi driver >> >> >> >> =============================================== >> >> [EMAIL PROTECTED] ~]# /sbin/modprobe ide-scsi >> >> =============================================== >> >> >> >> Made sure it worked >> >> >> >> =============================================== >> >> [EMAIL PROTECTED] ~]# mt -f /dev/nst0 status >> >> SCSI 2 tape drive: >> >> File number=0, block number=0, partition=0. >> >> Tape block size 512 bytes. Density code 0x45 (QIC-3095-MC (TR-4)). >> >> Soft error count since last status=0 >> >> General status bits on (41010000): >> >> BOT ONLINE IM_REP_EN >> >> ================================================ >> >> >> >> Ok, I'm ready to start test number one >> >> >> >> ================================================= >> >> [EMAIL PROTECTED] ~]# mt -f /dev/nst0 erase >> >> [EMAIL PROTECTED] ~]# mt -f /dev/nst0 rewind >> >> [EMAIL PROTECTED] ~]# tar cvf /dev/nst0 . >> >> ./ >> >> ./install.log >> >> ./.bashrc >> >> ./.bash_profile >> >> ./.gnupg/ >> >> ./.gnupg/secring.gpg >> >> ./.gnupg/trustdb.gpg >> >> ./.gnupg/pubring.gpg~ >> >> ./.gnupg/pubring.gpg >> >> ./.gnupg/gpg.conf >> >> ./.cpan/ >> >> ./.cpan/sources/ >> >> ./.cpan/sources/MIRRORED.BY >> >> ./.mysql_history >> >> ./.bash_logout >> >> ./.cshrc >> >> ./.bash_history >> >> ./.tcshrc >> >> ./anaconda-ks.cfg >> >> ./install.log.syslog >> >> [EMAIL PROTECTED] ~]# mt -f /dev/nst0 rewind >> >> [EMAIL PROTECTED] ~]# tar tvf /dev/nst0 >> >> drwxr-x--- root/root 0 2005-11-19 20:05:45 ./ >> >> -rw-r--r-- root/root 13431 2005-05-30 17:47:26 ./install.log >> >> -rw-r--r-- root/root 176 2005-02-22 03:22:18 ./.bashrc >> >> -rw-r--r-- root/root 191 2005-02-22 03:22:18 ./.bash_profile >> >> drwx------ root/root 0 2005-11-21 23:29:40 ./.gnupg/ >> >> -rw------- root/root 0 2005-05-30 17:46:09 >./.gnupg/secring.gpg >> >> -rw------- root/root 1200 2005-08-01 21:24:12 >./.gnupg/trustdb.gpg >> >> -rw------- root/root 4010 2005-06-08 23:41:41 >./.gnupg/pubring.gpg~ >> >> -rw------- root/root 5263 2005-07-19 13:26:17 >./.gnupg/pubring.gpg >> >> -rw------- root/root 8075 2005-05-30 17:46:09 ./.gnupg/gpg.conf >> >> drwxr-xr-x root/root 0 2005-11-19 20:05:45 ./.cpan/ >> >> drwxr-xr-x root/root 0 2005-11-19 20:06:00 ./.cpan/sources/ >> >> -rw-r--r-- root/root 147970 2005-11-19 20:06:00 >> >> ./.cpan/sources/MIRRORED.BY -rw------- root/root 0 2005-06-02 >> >> 19:34:04 ./.mysql_history -rw-r--r-- root/root 24 2005-02-22 >> >> 03:22:18 ./.bash_logout >> >> -rw-r--r-- root/root 100 2005-02-22 03:22:18 ./.cshrc >> >> -rw------- root/root 3506 2005-11-20 21:39:53 ./.bash_history >> >> -rw-r--r-- root/root 102 2005-02-22 03:22:18 ./.tcshrc >> >> -rw-r--r-- root/root 1050 2005-05-30 17:47:27 ./anaconda-ks.cfg >> >> -rw-r--r-- root/root 3281 2005-05-30 17:46:09 >./install.log.syslog >> >> ======================================================= >> >> >> >> So far so good. >> >> >> >> In bacula-dir.conf I placed >> >> >> >> ======================================================= >> >> Storage { >> >> Name = Tarvan >> >> Address = localhost >> >> SDPort = 9103 >> >> Password = >> >> Device = /dev/nst0 >> >> Media Type = Tarvan >> >> } >> >> ==================================================== >> >> >> >> and in bacula-sd.conf I placed this (based on the OnStream tape drive >> >> >> >> ==================================================== >> >> Device { >> >> Name = Tarvan >> >> Description = "Tarvan drive on Linux" >> >> Media Type = Tarvan-4 >> >> Archive Device = /dev/nst0 >> >> AutomaticMount = yes; AlwaysOpen = yes >> >> Offline On Unmount = no >> >> Fast Forward Space File = no #inserted this after test error >> >> # The min/max blocksizes of 32768 are *required* >> >> Minimum Block Size = 32768 >> >> Maximum Block Size = 32768 >> >> } >> >> ======================================================== >> >> >> >> Ok now to test it out >> >> >> >> ======================================================== >> >> [EMAIL PROTECTED] ~]# /usr/sbin/btape -c /etc/bacula/bacula-sd.conf >> >> /dev/nst0 Tape block granularity is 1024 bytes. >> >> btape: butil.c:258 Using device: "/dev/nst0" for writing. >> >> btape: btape.c:335 open_dev /dev/nst0 OK >> >> *test >> >> >> >> === Write, rewind, and re-read test === >> >> >> >> I'm going to write 1000 records and an EOF >> >> then write 1000 records and an EOF, then rewind, >> >> and re-read the data to verify that it is correct. >> >> >> >> This is an *essential* feature ... >> >> >> >> btape: btape.c:786 Wrote 1000 blocks of 32668 bytes. >> >> btape: btape.c:465 Wrote 1 EOF to /dev/nst0 >> >> btape: btape.c:802 Wrote 1000 blocks of 32668 bytes. >> >> btape: btape.c:465 Wrote 1 EOF to /dev/nst0 >> >> btape: btape.c:811 Rewind OK. >> >> 1000 blocks re-read correctly. >> >> Got EOF on tape. >> >> 1000 blocks re-read correctly. >> >> === Test Succeeded. End Write, rewind, and re-read test === >> >> >> >> >> >> === Write, rewind, and position test === >> >> >> >> I'm going to write 1000 records and an EOF >> >> then write 1000 records and an EOF, then rewind, >> >> and position to a few blocks and verify that it is correct. >> >> >> >> This is an *essential* feature ... >> >> >> >> btape: btape.c:898 Wrote 1000 blocks of 32668 bytes. >> >> btape: btape.c:465 Wrote 1 EOF to /dev/nst0 >> >> btape: btape.c:914 Wrote 1000 blocks of 32668 bytes. >> >> btape: btape.c:465 Wrote 1 EOF to /dev/nst0 >> >> btape: btape.c:923 Rewind OK. >> >> Reposition to file:block 0:4 >> >> 22-Nov 18:34 btape: btape Error: block.c:264 Volume data error at 0:4! >> >> Wanted ID >> >> >> >> : "BB02", got "". Buffer discarded. >> >> >> >> btape: btape.c:979 Read block 5 failed! file=0 blk=4. ERR=Input/output >> >> error >> >> >> >> btape: btape.c:989 This may be because the tape drive block size is >not >> >> set to variable blocking as normally used by Bacula. >> >> Please see the Tape Testing chapter in the manual and >> >> look for using mt with defblksize and setoptions >> >> If your tape drive block size is correct, then perhaps >> >> your SCSI driver is *really* stupid and does not >> >> correctly report the file:block after a FSF. In this >> >> case try setting: >> >> Fast Forward Space File = no >> >> in your Device resource. >> >> ===================================================================== >> >> >> >> Yeek! >> >> >> >> I have NFI about block size so I thought I would just throw in Fast >> >> Forward Space File = no as it suggested. >> >> >> >> I ran the test again >> >> >> >> ====================================================================== >> >> === Write, rewind, and re-read test === >> >> >> >> I'm going to write 1000 records and an EOF >> >> then write 1000 records and an EOF, then rewind, >> >> and re-read the data to verify that it is correct. >> >> >> >> This is an *essential* feature ... >> >> >> >> btape: btape.c:786 Wrote 1000 blocks of 32668 bytes. >> >> btape: btape.c:465 Wrote 1 EOF to /dev/nst0 >> >> btape: btape.c:802 Wrote 1000 blocks of 32668 bytes. >> >> btape: btape.c:465 Wrote 1 EOF to /dev/nst0 >> >> btape: btape.c:811 Rewind OK. >> >> 1000 blocks re-read correctly. >> >> Got EOF on tape. >> >> 1000 blocks re-read correctly. >> >> === Test Succeeded. End Write, rewind, and re-read test === >> >> >> >> >> >> === Write, rewind, and position test === >> >> >> >> I'm going to write 1000 records and an EOF >> >> then write 1000 records and an EOF, then rewind, >> >> and position to a few blocks and verify that it is correct. >> >> >> >> This is an *essential* feature ... >> >> >> >> btape: btape.c:898 Wrote 1000 blocks of 32668 bytes. >> >> btape: btape.c:465 Wrote 1 EOF to /dev/nst0 >> >> btape: btape.c:914 Wrote 1000 blocks of 32668 bytes. >> >> btape: btape.c:465 Wrote 1 EOF to /dev/nst0 >> >> btape: btape.c:923 Rewind OK. >> >> Reposition to file:block 0:4 >> >> btape: btape.c:979 Read block 5 failed! file=0 blk=4. ERR=Input/output >> >> error >> >> >> >> btape: btape.c:989 This may be because the tape drive block size is >not >> >> set to variable blocking as normally used by Bacula. >> >> Please see the Tape Testing chapter in the manual and >> >> look for using mt with defblksize and setoptions >> >> If your tape drive block size is correct, then perhaps >> >> your SCSI driver is *really* stupid and does not >> >> correctly report the file:block after a FSF. In this >> >> case try setting: >> >> Fast Forward Space File = no >> >> in your Device resource. >> >> ================================================================= >> >> >> >> Ok, I guess I really do need to do something about the block size. >> >> >> >> Can anyone point me in the right direction from here?? >> > >> >As you said yourself, these IDE drives are a nightmare ... see my >comments >> >on >> >the Travan drive about a week ago, or was my email to you? >> > >> >I am assuming that you told your tape drive what the block size is -- as >> >the >> >btape message suggests. If not, that is the first thing to do. >> > >> >Anyway, after that my best guess is that the driver may not be keeping >> >track >> >of the tape position correctly. You might try setting: >> > >> > Use mtiocget = no >> > >> >Please check the name of the directive -- I might have a silly typo in >> >what I >> >wrote. >> > >> >Another thing to do is to set debug say -d100 or -d200 on the command >> >line. >> >This will give you a lot more information about what is going on inside >> >Bacula's tape handler. >> > >> >-- >> >Best regards, >> > >> >Kern >> > >> > ("> >> > /\ >> > V_V >> >> Thanks Kern >> >> I did do this as suggested on the test page: >> >> mt -f /dev/nst0 defblksize 32768 >> >> But looking back over the output of this command: >> >> mt -f /dev/nst0 status >> >> I noticed this: >> >> Tape block size 512 bytes >> >> Out of interest I set the block size to 512 >> >> mt -f /dev/nst0 defblksize 512 >> (and set 512 in bacula-sd.conf) >> >> When I ran the test it work 100% >> >> But I read that having the block size set so small is very bad so I tried >> it at 1024, but this broke it again :( >> >> So I guess my question is - How bad is it to use the block size of 512? >> >> I'm only using 4GB tapes and will generally only backup around 1 Gig >total >> of data. >> > >Interesting discovery. I will remember that for the next time. Well, >apparently your IDE driver always breaks the blocks into 512 bytes. Most >old >drivers default to 512 blocks but allow other sizes. If 512 works for you, >all the better, but please be sure to check using the fill test to make >sure >that data spanning tapes works. Of course, if you never write more than >1GB >you won't have the problem and the test won't be necessary. > >How bad is a 512 block size? It is a question of performance and tape >usage. >I don't know, one would have to do some tests, but if your drive (or more >likely the IDE driver) requires it, you don't have much choice. > >Before you put it into production, you might try removing the Fast Forward >... >restriction you put in. It may just work, and will give you better >performance. > >And finally, please do a few backups and restores with real data to the >drive >before putting it into production ... Once you are sure it works, please >send an email to the bacula-devel list with your final Device resource >with >your comments (i.e. must do mt -f /dev/... defblksize 512) ... I would >like >to add it to the doc or perhaps default bacula-sd.conf file. > >-- >Best regards, > >Kern > > ("> > /\ > V_V I tried removing the Fast Forward but I received an error message and the test reset it to no. At the end of the test I received a message to add these two lines Fast Forward Space File = no Hardware End of Medium = no So I've done that. I'll run a fill test now to see how that goes and check how it went tomorrow (bed time for me). I'll report back my findings once I've done the backups as suggested - unless I break something in the meantime, then I'll report back with more questions :) ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
