Odd DLT behavior

[Chapter11]

I'm working on a system that uses a DLT drive (shows up as 35G capacity, so it's a 4000 or 7000 I think, I don't use a lot of DLT myself). It's being fed DLT4 tapes.

When I originally set up the backups for this machine, I tested a variety of block sizes, 1k, 2k, 4k, 8k, 16k, 32k, to find the most efficient block size it could use. At the time of setup, that ended up being 32k.

Now I can't use anything larger than 2k. I wouldn't have a problem with this as long as it works except that it extends the backup time by quite a bit.

Nothing in the error report, no changes to hardware, and we're still using the same tapes.

Does anyone have any ideas on what I can do to get the thing using a decently large block size again?

 

[DSMARWAY]

hi,

one quick thing to check is , where are you setting the block size
i.e. on the tape drive itself or in your backup script.
if on the tape drive change it to block size 0 and set it in your backup script and try it .

 

[Chapter11]

The script performs a "chdev -l rmt0 -a block_size=32768" although at the moment it's 2048 instead. I'll run it tonight set to 0 and see how it turns out.

 

[DSMARWAY]

hi,

when i mean change it in your backup script i mean , if you use the backup command use the -b option i.e.
backup -0 -b64 -L 100g -f /dev/rmt0 filesystem
or whatever backup command you use change it there to use the required block size, and set tape drive to 0

HTH

 

[Chapter11]

Currently my backup command doesn't use the -b option. I read up on the manpage about that, and it says the default value (for backup-by-inode) should result it in using 32k blocks. I'm going to leave it that way for tonight's run. If that doesn't work, I'll start tweaking it.