Very Computer

by **Chris Co** » Fri, 31 Dec 2004 02:56:23

From what we've seen, you have to specify the tape size
in order to handle multi tape backups with star... but
we didn't have to do that with tar.... are we just missing
the option??

by **Joerg Schilli** » Fri, 31 Dec 2004 09:49:10

Quote:> From what we've seen, you have to specify the tape size
>in order to handle multi tape backups with star... but
>we didn't have to do that with tar.... are we just missing
>the option??

tar does not handle multi volume archives at all unless you
have the source and thus know how to change /etc/default/tar
in order to set up a fixed medium size value. Note that this
only works with non-tape devices such as floppies.

Star allows you either to specify a fixed tape size on the command line
or to request star to find out the actual tape size dynamically.
This is the only way to deal with compressing tape drives in a useful
way.

Just read the man page for more information.....

--

URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

by **Chris Co** » Sat, 01 Jan 2005 06:29:29

>>From what we've seen, you have to specify the tape size
>>in order to handle multi tape backups with star... but
>>we didn't have to do that with tar.... are we just missing
>>the option??

> tar does not handle multi volume archives at all unless you
> have the source and thus know how to change /etc/default/tar
> in order to set up a fixed medium size value. Note that this
> only works with non-tape devices such as floppies.

Really? Seems like before that it would hit the end of the tape
and we could specify a different device (or unload/load and specify)
and it would work.

That doesn't work? I think that's what you are saying right?

Quote:
> Star allows you either to specify a fixed tape size on the command line
> or to request star to find out the actual tape size dynamically.
> This is the only way to deal with compressing tape drives in a useful
> way.

> Just read the man page for more information.....

Thanks... we really like star.

by **Andreas Almrot** » Sat, 01 Jan 2005 20:13:22

>>>>From what we've seen, you have to specify the tape size

>>>>in order to handle multi tape backups with star... but
>>>>we didn't have to do that with tar.... are we just missing
>>>>the option??

>>>tar does not handle multi volume archives at all unless you
>>>have the source and thus know how to change /etc/default/tar
>>>in order to set up a fixed medium size value. Note that this
>>>only works with non-tape devices such as floppies.

>>Really? Seems like before that it would hit the end of the tape
>>and we could specify a different device (or unload/load and specify)
>>and it would work.

>>That doesn't work? I think that's what you are saying right?

>tar has never done this for me. This behavior sounds like ufsdump.

Or GNU tar... gtar -M worked for me back in the QIC60 times at least...

/A

by **Joerg Schilli** » Sat, 01 Jan 2005 20:33:45

Quote:>>tar has never done this for me. This behavior sounds like ufsdump.

>Or GNU tar... gtar -M worked for me back in the QIC60 times at least...

I am not sure if GNU tar has been fixed, but you should note that
at least until six months ago, GNU tar refused to read back
approx. 5% of the multivolume continuation volumes. I would not call
this "GNU tar supports multiolume".....

--

URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

by **Andreas Almrot** » Sun, 02 Jan 2005 04:25:50

>>>tar has never done this for me. This behavior sounds like ufsdump.

>>Or GNU tar... gtar -M worked for me back in the QIC60 times at least...

>I am not sure if GNU tar has been fixed, but you should note that
>at least until six months ago, GNU tar refused to read back
>approx. 5% of the multivolume continuation volumes. I would not call
>this "GNU tar supports multiolume".....

I really don't know about the 5%, but I have never experienced the
problem you mention on QIC60 (device? don't even remember the vendors)
and DDS3 tapes (on HP and Sony DAT devices) when using gtar on Solaris OE.
My response to (however not 100% clear I realised later) the thread was
that the OP might have used gtar instead of tar.

Question: Using multi-volume has always been to me that when the
application received EOF (or whatever it the signal is), it just makes
sure it saves the unwritten buffer until able to write on next media. If
the HW compression is in place, the device still reports EOF, and the
application continues from there on next tape. Shouldn't the application
be able to cope with this and not use explicit size values? Only
asking... I would be interested in pointers to more information on this
topic.
I'm primarily using IBM's Tivioli Storage Manager and it dynamically
handles both SW and HW compression, but I have never really bothered to
look into this in more detail.

/A

by **Chris Co** » Sun, 02 Jan 2005 13:54:48

...

Quote:> I really don't know about the 5%, but I have never experienced the
> problem you mention on QIC60 (device? don't even remember the vendors)
> and DDS3 tapes (on HP and Sony DAT devices) when using gtar on Solaris OE.
> My response to (however not 100% clear I realised later) the thread was
> that the OP might have used gtar instead of tar.

Just for the record... I can't recall. We've been using star now.
Maybe I just dreamed the whole thing (or perhaps wishful thinking?).

by **Joerg Schilli** » Sun, 02 Jan 2005 23:49:09

Quote:>>>Or GNU tar... gtar -M worked for me back in the QIC60 times at least...

>>I am not sure if GNU tar has been fixed, but you should note that
>>at least until six months ago, GNU tar refused to read back
>>approx. 5% of the multivolume continuation volumes. I would not call
>>this "GNU tar supports multiolume".....

>I really don't know about the 5%, but I have never experienced the
>problem you mention on QIC60 (device? don't even remember the vendors)
>and DDS3 tapes (on HP and Sony DAT devices) when using gtar on Solaris OE.
>My response to (however not 100% clear I realised later) the thread was
>that the OP might have used gtar instead of tar.

If you like to verify the problem, check the GNU tar multi volume test
archives on:

ftp://ftp.berlios.de/pub/star/testscripts/

Quote:>Question: Using multi-volume has always been to me that when the
>application received EOF (or whatever it the signal is), it just makes
>sure it saves the unwritten buffer until able to write on next media. If
>the HW compression is in place, the device still reports EOF, and the
>application continues from there on next tape. Shouldn't the application
>be able to cope with this and not use explicit size values? Only
>asking... I would be interested in pointers to more information on this
>topic.

In order to need several things to work correctly:

- The firmware of the tape drive needs to make sure that
in case of a propagated EOF the block is not written
Note that QIC tapes are unblocked and thus may do partial
writes.

- The driver needs to behave correctly.

- If the tar archive program needs either to do nothing
(This only works for non QIC type drives) or to deal in a
usefule way with the results.

What star does (and GNU tar tries to do) is to create the continuation
medium im a way that allows to start reading the archive from one
of the continuation mmedia.

--

URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Very Computer

Star tape size for multi tape backups question

Star tape size for multi tape backups question

Star tape size for multi tape backups question

Star tape size for multi tape backups question

Star tape size for multi tape backups question

Star tape size for multi tape backups question

Star tape size for multi tape backups question

Star tape size for multi tape backups question

Star tape size for multi tape backups question