Re: Optimal tape block size?

In article <33FF4DB0.9ECE899D@echonyc.com>, Cosmo Lee <*NO- SPAM*cosmo@echonyc.com> writes >Platform: >Unixware 2.1, Informix Online 7.22, Compaq Proliant 1500, Archive Python >28388 tape drive. > >1 ) > >How does one determine the optimal block size to use when copying to a >tape drive? Informix Online supplies an archive utility `ontape`, >which requires a tape block size to be set. When copying to a remote >tape drive, I see that `ontape` utilizes the `dd` command. > Will you be copying to a local tape drive or a remote one? First I would set the tape drive to variable length blocks, this is not neccessary on other versions of UNIX e.g. SCO (OK AIX is the other exception!). Having to set the block size and keep it the same when reading the tape Seems like a silly Unixware limitation. Then try the following tape sizes 16K and 64K. I assume you are talking about archives rather then logical log backups....in this case try both sizes and see which one is faster. I would imagine the 64K but your mileage may vary. >I thought one could experiment with `dd` to try to determine the optimal >block size setting, but I have some questions about the input block size Why bother? Also dd will write to the drive at full speed whereas ontape has to get the data via online and hence will send data to the tape drive at a different rate and may stall occasionally waiting for data from online. >vs the output block size. When the Unix vxfs file systems are created >I choose 1024 as the file system block size. For the vxfs file system >it seems that the "real" block sizes are 512, but the logical block size >is 1024. The Informix raw slices use 2048 byte "pages". > >So: if I'm copying from a Unix file system do I use ibs=1024 or 512? >And when copying from an Informix Online slice do I use ibs=2048? > > >2 ) > >This from `man dd` is of concern: > > Do not use dd to copy files between file systems having > different block sizes. > I've never seen this before...files are just a sequence of bytes under ALL version of UNIX, seems like Unixware is broken.. >Does this mean that my ibs has to be set to the same size as my obs??? >It seems to say this, but I see differing input and output block sizes >all the time. Or is the tape not considered to be a "file system", >and the `man` entry does not apply? > > > >3 ) > >Does the following mean that the safest block size to use when copying >out to tape is 512??? > No the DEFAULT block size is 512 bytes. > The default mode for I/O from any magnetic tape, such as > QICtape, 9-track, or DAT is fixed-length blocks which are >512 > bytes long. > > Reading from magnetic tape in any fixed-length block length, > besides the block length that the media was written in > originally, will cause an I/O error. In order to read a >tape > that was written using some block length besides the default > > of 512, use the tapecntl(1) command (qv) to either set the > block length of the drive to match the block length of the > media, or to set the drive into variable block length mode. > > dd does not always require block sizes that are in multiples > > of 512 bytes. Block size is device dependent. If input ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >data > blocks are not a multiple of 512, however, the read side >will > have no error messages, but the write side might have a > ``write error'' message. dd transfers correctly if the >input > data block sizes are a multiple of 512. > >4 ) > >Where does one *learn* about how to use `dd`. I see plenty of >references to this command, but nothing that really explicates its >workings. The man entry is not too good for this. > >Thanks for any clarification. >-- >* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > Please reply to Newsgroup. >ADDRESS ALTERED TO FOIL SPAMMERS: Remove "*NO-SPAM*" to reply. > >Cosmo Lee Multi-User Computer Systems Brooklyn, NY > > "JUST SAY 'NO' TO SPAM" >* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > -- David Williams