Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > >> Curious as to why tar worked when btape did not, I found this. For >> portability reasons, tar appears to always use a physical block size of >> 512 bytes. See >> http://www.gnu.org/software/tar/manual/html_section/tar_73.html. Perhaps >> that explains the difference in how tar writes to tape versus how btape >> writes to tape. >> > > This is a misinterpretation. > > The physical *tape* block size or record size is a multiple of the 512 > byte block size, as determined by the '-b' resp. '--blocking-factor' > option. >
You are correct. Tar full_write() and safe_write() functions end up trying to write an entire record of bs*512 bytes with a write() system call. Looking at btape.c, it looks like btape rawfill_cmd() writes a block (of blocksize bytes) with a single write() system call as well. So this is a very strange problem, indeed. The only difference that I can see is that the full_write() / safe_write() functions in tar attempt the write multiple times if need be and attempt to finish (it seems) partial writes. Btape fails immediately if the write() system call fails to write the requested number of bytes. However, btape should be issuing a "Write failed at block " message if the write fails. That error message contains an error string corresponding to the errno that was set when the write() failed, which could be helpful. Christopher Litauer's initial message does not include such an error message after the "Begin writing raw blocks of " message, so I don't know if he just didn't include it or if the only messages he saw were the "bad page state" syslog messages. If there was no "Write failed at block" message, then the write() system call never returned, in which case it is a real mystery (to me) as to how tar can possibly work with the same block size. This is definitely a driver problem. Still, it is a bit frustrating that btape does not work when tar does. > Best regards, > > Wolfgang Denk > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users