Star's users help forum ()

Joerg Schilling | 4 Mar 2011 13:29

Re: star tape I/O suggestion

markk <at> clara.co.uk wrote:

> Yes, that was the point of my suggestion. Instead of writing one tape
> block at a time, if you set the tape drive to fixed-block mode by doing
> e.g.
>   mt -f /dev/nst0 setblk 32768
> you can then tell star to write in larger chunks, say bs=524288. In that
> case, each 512KB that star writes should (subject to the tape driver) get
> written to tape using one WRITE command of sixteen 32KB blocks.

Try to avoid this, it creates tapes that cannot be read on all platforms and 
that need manual intervention on others.

> So there will be no interchange problems due to large tape block size, and
> no inefficiency from writing one small tape block at a time.

See above, UNIX expects variable blocked tapes

> However, the disadvantage is that star pads the written data to a multiple
> of 512KB, when it only needs to be padded to the tape block size (32KB
> here). That's not a huge amount of wasted data, but if someone is using
> much larger transfers on a modern tape drive, the amount wasted could be
> larger. E.g. writing 256KB blocks 32MB at a time. And if the user later
> copies the tar archive from tape to a file on disk, the extra padding will
> waste disk space.
>
> So ideally, star would be told two things:
>  - the tape block size (bs= or blocks=)
>  - the maximum number of blocks in each I/O operation (or alternatively,
> the maximum I/O size)

(Continue reading)

headers

markk | 4 Mar 2011 22:02

Re: star tape I/O suggestion

Joerg Schilling wrote:
>> Yes, that was the point of my suggestion. Instead of writing one tape
>> block at a time, if you set the tape drive to fixed-block mode by doing
>> e.g.
>>   mt -f /dev/nst0 setblk 32768
>> you can then tell star to write in larger chunks, say bs=524288. In that
>> case, each 512KB that star writes should (subject to the tape driver)
>> get
>> written to tape using one WRITE command of sixteen 32KB blocks.
>
> Try to avoid this, it creates tapes that cannot be read on all platforms
> and that need manual intervention on others.
>
>> So there will be no interchange problems due to large tape block size,
>> and no inefficiency from writing one small tape block at a time.
>
> See above, UNIX expects variable blocked tapes

I was under the impression that writing several blocks with one WRITE
command (fixed-length block mode) writes exactly the same data to tape as
several successive one-block writes (in fixed or variable block mode). In
other words, that there's no such thing as a variable blocked tape or a
fixed block tape, they are the same thing. And that any tape could later
be read in variable-block mode.

Could you explain a bit about what problems that can cause? Does it only
apply to certain types of tape/drive? What manual intervention would be
needed to read such a tape in variable-block mode?

>> So ideally, star would be told two things:

(Continue reading)