Re: star tape I/O suggestion

[email protected] 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=3D524288. 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 an=
d =

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=3D or blocks=3D)
>  - the maximum number of blocks in each I/O operation (or alternatively,
> the maximum I/O size)
> Then star would perform I/O in maxblocks*bs byte chunks, except the last
> write which could be a lower multiple of bs.

See man page, star introduced -P in 1985.

J=F6rg

-- =

 EMail:[email protected] (home) J=F6rg Schilling D-13353 Be=
rlin
       [email protected]                (uni)  =

       [email protected] (work) Blog: http://schily.blogs=
pot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily