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
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 2182 at 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? Thanks, Renee Gehlbach ___ 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
network problems after upgrade
Hello, I recently updated a FreeBSD system that has been running fine on 6.2 to 7.0. I rebuilt world kernel, installed world kernel, mergemastered, then rebooted. Now both network cards (em0, an Intel Pro/1000 v6.7.3, and rl0, an SMC eznet-10/100) are giving continual watchdog timeouts. Ifconfig shows them as active, with appropriate settings. There are no IRQ conflicts that I can see. Pinging loopback and the ip address of each card succeeds, but we can't ping anything outside of the system. We've tried disabling ipf; we've taken out each card in turn, trying it with only one card; we've tried building the generic kernel, just in case we accidentally took out something necessary; we've taken rc.conf down to just defining the gateway and addresses for the network interfaces; at this point I don't know what to try next. I can restore from backup to cvsup and get any current changes, then rebuild, but I hate going through all of that without any reason to believe anything will change. Any ideas for further troubleshooting would be very welcome! Renee -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
