Re: Problem reading from tape drive -- SOLVED, or at least a workaround
Is there any way I could test to make sure this is in fact what's happening? Try writing several files to the tape, each in it's own operation, and issue a 'mt -bsf' between each operation. THEN try reading from the tape. with just successive 'read' operations. *NO* 'mt' positioning If everything is working 'properly', there will be *ONLY*ONE* file on the tape. If there is an O/S failure to 'backspace on close' you'll get all the original files, one on each read attempt. If the O/S has a _complete_ 'failure to backspace', you'll get a tape that functions identially to your earlier tests -- you can find all the file by 'mt -fsf' between reads Other things to try. 1) *write* a multi-file tape under Unbuntu, and try to read it under FreeBSD. 2) *write* a multi-file tape under FreeBSD, and try to read it under Unbuntu. 3) If there are read issues, see if the 'mt -fsf' hack allows you to find everything. OK, it's definitely an O/S failure to backspace on close, because the tape does read properly when I manually backspace after each file. Unfortunately, the workaround of running mt -fsf after every file read if it worked, 'mf -bsf' after every _write_ would be a better solution.grin But it probably suffers from the same 'not really usable' defect. *cheers* And YES That's a usable workaround! Luckily enough, Bacula will run a script after each backup job, all I'll have to do is add a mt -bsf command to that script! _I_ have no clue what 'bacula' is -- sounds sort-of like a Transylvanian back-up utility. One with 'fangs' init, and issues with mirrors.grin Close! It's a multi-platform client-server backup application. Its tagline used to be something like Comes in the night, and sucks the essence from your computers. When I went to check the precise wording, though, it's no longer on their logo. I guess someone objected.too bad, I got a kick from that tagline. I find it to be a great open-source replacement for backup exec. I can have the Bacula server and tape drive on one FreeBSD or Linux box, and install clients on all of my other FreeBSD Linux servers, and Linux Windows desktops to back them all up to that one tape drive. Thanks for all of your help!! Renee ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problem reading from tape drive
On 08/25/2011 06:38 PM, Robert Bonomi wrote: From owner-freebsd-questi...@freebsd.org Thu Aug 25 13:57:20 2011 Date: Thu, 25 Aug 2011 14:24:57 -0400 From: Renee Gehlbachfbsd...@gehlbach.com To: questi...@freebsd.org Cc: Subject: Problem reading from tape drive I recently purchased a FreeBSD-compatible SAS card (an Adaptec ASR 2045) and moved our backup server from Ubuntu to FreeBSD 8.2. I am trying to set up the backup software, but am having problems with the tape drive. Hopefully this is a duh type question, since I have a lot more experience working with tape drives in Ubuntu than FreeBSD. I installed bacula, and ran the test function in the btape utility. It wrote 1 blocks, wrote EOF, wrote 1 blocks, wrote EOF, wrote EOF. Rewound the tape. Read 1 blocks, failed reading the second 1 blocks. I had no luck researching the bacula error message, so I switched to mt and tar for further troubleshooting. camcontrol devlist does show the tape drive: backup# camcontrol devlist QUANTUM ULTRIUM 3 2182at scbus2 target 0 lun 0 (sa0,pass0) So then I went into a directory that had one subdirectory, which contained several plain text logfiles. I did four tars, alternating between that directory and the subdirectory (so I would be able to see a difference between the tar files). backup# mt -f /dev/nsa0 rewind backup# tar -cf /dev/nsa0 * backup# cd log/ backup# tar -cf /dev/nsa0 * backup# cd .. backup# tar -cf /dev/nsa0 * backup# cd log/ backup# tar -cf /dev/nsa0 * So far so good. Then I went back to read those tar files. backup# mt -f /dev/nsa0 rewind backup# tar -tf /dev/nsa0 log/ log/mbw01.log (insert rest of correct tar listing) backup# tar -tf /dev/nsa0 tar: Unrecognized archive format tar: Error exit delayed from previous errors. Sosame results as bacula's tape test utility was giving.it writes, it reads the first file, then errors on trying to read the second file. However: backup# mt -f /dev/nsa0 rewind backup# tar -tf /dev/nsa0 log/ log/mbw01.log (insert rest of correct tar listing) backup# mt -f /dev/nsa0 fsf backup# tar -tf /dev/nsa0 mbw01.log (insert rest of correct tar listing) backup# mt -f /dev/nsa0 fsf backup# tar -tf /dev/nsa0 log/ log/mbw01.log (insert rest of correct tar listing) backup# mt -f /dev/nsa0 fsf backup# tar -tf /dev/nsa0 mbw01.log (insert rest of correct tar listing) backup# mt -f /dev/nsa0 fsf So, when I tell it to forward space file at the end of each tar file, it is able to read all four files correctly. This leaves me scratching my head, and wondering what the heck I've set up wrong. Any ideas? Tape drivers _always_ write two EOFs when the tape device is closed. This ensures there is always a valid 'EOT' on the tape. They're _suppoesed_ to backspace over the 2nd EOF mark, so that a subsequent write has only one EOF between it and the prior file. Looks like your drive isn't doing the 'backspace' right. I suspect the 'easiest' work around is the one you've discovered -- do an 'mt -fsf' after avery tape file 'read'. OK, I feel pretty dense When you're saying they write two EOFs when the device is closed, would this happen every time you write a file? Or would it be every time the tape is unmounted? Or would that depend on the program you're using? Is there any way I could test to make sure this is in fact what's happening? And would the problem with it not doing the backspace right be an issue with the FreeBSD tape driver? Or SCSI card driver? Or what driver? Obviously not a problem with the drive itself, since I don't have this problem with Ubuntu. Unfortunately, the workaround of running mt -fsf after every file read isn't really usable workaround.I need the tape drive to work with bacula, not just running tars. Where do I go from here? Thanks, Renee ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problem reading from tape drive
From owner-freebsd-questi...@freebsd.org Fri Aug 26 13:51:51 2011 Date: Fri, 26 Aug 2011 14:50:23 -0400 From: Renee Gehlbach fbsd...@gehlbach.com To: questi...@freebsd.org Cc: Subject: Re: Problem reading from tape drive On 08/25/2011 06:38 PM, Robert Bonomi wrote: From owner-freebsd-questi...@freebsd.org Thu Aug 25 13:57:20 2011 Date: Thu, 25 Aug 2011 14:24:57 -0400 From: Renee Gehlbachfbsd...@gehlbach.com To: questi...@freebsd.org Cc: Subject: Problem reading from tape drive [[ sneck ]] So, when I tell it to forward space file at the end of each tar file, it is able to read all four files correctly. This leaves me scratching my head, and wondering what the heck I've set up wrong. Any ideas? Tape drivers _always_ write two EOFs when the tape device is closed. This ensures there is always a valid 'EOT' on the tape. They're _suppoesed_ to backspace over the 2nd EOF mark, so that a subsequent write has only one EOF between it and the prior file. Looks like your drive isn't doing the 'backspace' right. I suspect the 'easiest' work around is the one you've discovered -- do an 'mt -fsf' after avery tape file 'read'. OK, I feel pretty dense When you're saying they write two EOFs when the device is closed, would this happen every time you write a file? Authortative answer it depends. you can 'cat' several files to te tape device, in one invocation, and there will be no EOF marks between the source files. I meant _exactly_ what I said, in describing tape operationss. To wit: Every time an application calls close(2) (or fclose(3), which calls close(2)) *or* exits without closing an open file in which case the O/S invokes close(2) on every open file descrriptor. Or would it be every time the tape is unmounted? Or would that depend on the program you're using? Nope, it's automatic, and internal to th O/S. Is there any way I could test to make sure this is in fact what's happening? Try writing several files to the tape, each in it's own operation, and issue a 'mt -bsf' between each operation. THEN try reading from the tape. with just successive 'read' operations. *NO* 'mt' positioning If everything is working 'properly', there will be *ONLY*ONE* file on the tape. If there is an O/S failure to 'backspace on close' you'll get all the original files, one on each read attempt. If the O/S has a _complete_ 'failure to backspace', you'll get a tape that functions identially to your earlier tests -- you can find all the file by 'mt -fsf' between reads Other things to try. 1) *write* a multi-file tape under Unbuntu, and try to read it under FreeBSD. 2) *write* a multi-file tape under FreeBSD, and try to read it under Unbuntu. 3) If there are read issues, see if the 'mt -fsf' hack allows you to find everything. And would the problem with it not doing the backspace right be an issue with the FreeBSD tape driver? Or SCSI card driver? Or what driver? Yes. grin A prime candiate would be sa(4) . See 'filemark handling' at the end of the manpage. mtio(4) is another candidate, see para. 3 of that manpage. And it is _possible_, albeit *unlikely, that somebody screwed up on the scsi card driver and the code for that particular command is broken. Obviously not a problem with the drive itself, since I don't have this problem with Ubuntu. To be precise, it is not a case of a _defective_ drive. This does not eliminate the possibiity of 'non standard' behavior (where the drive is 'working as the manufacturer intends'), with Unbuntu having an embedded 'work around'. I've had too much experience with *REALLY*weird* problems to dismiss -anything-, out of hand. 30+ years ago, I discovered inadvertently) a very specific set of circumstances where I could render a mainframe _completely_ unusable -- by simply _rewinding_ a mag tape, as a regular user. The only recovery was a re-boot of the mainframe. If folks caught it _early_enough_, a reboot directive from the operator console was effective. If it developed a bit further, the *only* recourse/remedy was the 'big red button'. To add to the 'fun', this particular vulnerability was *confirmed* to exist on at least three separate, unrelated, operating systems running on _incompatible_ hardware. Unfortunately, the workaround of running mt -fsf after every file read if it worked, 'mf -bsf' after every _write_ would be a better solution. grin But it probably suffers from the same 'not really usable' defect. isn't really usable workaround.I need the tape drive to work with bacula, not just running tars. Where do I go from here? All I can contribute it the offspring of an rhinoceros mating with an elephant. In other words, elephino'. groan _I_ have no clue what 'bacula' is -- sounds sort-of like a Transylvanian back-up utility. One
