A query passed by earlier today about problems with ftape 3.04 under Red
Hat 6.1. Unfortunately, I managed to delete my copies, and I see it was not
mirrored to fa.linux.tape. If someone has the email address of the
questioner, please forward this ... Thanks.

I had general problems with ftape 3.04 under Red Hat 6.1, *until* I tried

mt -f /dev/rft0 setblk 0

(check that command syntax, since I'm not in Linux right now) *before*
trying to create any tape, even one with tar, which presumably defaults to
10k blocks, the same as zftape was set to in the kernel build (I rebuilt
the kernel and modules, so I'm sure of this). Without the above, I kept
getting strange errors in the middle of a backup, such as

ftape-write.c (ftape_write_segment_R8a09c846) - write error, retry 6 (1093). 
ftape-write.c (write_segment) - warning: 1 hard error(s) in written segment. 
ftape-rw.c (ftape_start_tape) - failed to reposition. 
ftape-write.c (ftape_start_writing_Ra99d81e3) -
        ftape_start_tape(segment_id,head->sector_offset) failed: -5. 
ftape-write.c (write_segment) - ftape_start_writing_Ra99d81e3(write_mode)
        failed: -5. 
ftape-write.c (ftape_write_segment_R8a09c846) - write_segment failed,
        error: -5. 
zftape-write.c (_zft_write) - ftape_write_segment_R8a09c846(zft_pos.seg_pos,
        zft_deblock_buf, FT_WR_ASYNC) failed: -5. 
zftape-ctl.c (_zft_close) - Error: unable to update header segments. 

While I'm *guessing*, it looks to me as if taht version of zftape had a
problem with the occassional short block that may get produced in a backup.
The command at the top is supposed to disable compression from zftape as I
understand it, and allow varying blocksizes. Anyway, it seems to have cured
my problems, although I believe no ftape compression is now done as the
tape is created.

The above assumes you have /dev/ftape pointing to /dev/rft0. If not, change
the command to fit your configuration.

I'm assuming you don't wish to upgrade to the newer ftape release (which
disables compression on output anyway I believe) ...

Jim

Reply via email to