Re: Compressed export to Tape
From: Dirk Breuer <Dirk_Breuer_at_p110.f5888.n240.z2.fidonet.org>
Date: 1995/08/07
Message-ID: <MSGID_2=3A240=2F5888.110=40fidonet.org_bb36db6a_at_fidonet.org>#1/1
It is a problem of the implementation of the LZW-algorithm used by the compress command. compress (on our hp-ux) used varying alphabets for compression from 9 to 15 bit length. So it would have to rewrite the tape when changing the length of the alphabet. We were recently told - facing a similar problem - to use tape drives with hardware compression. That's far better and more safe (and faster too).
If anyone has a better idea (like your named pipes) please let me know!
Date: 1995/08/07
Message-ID: <MSGID_2=3A240=2F5888.110=40fidonet.org_bb36db6a_at_fidonet.org>#1/1
c9527 # rrzc4.UUCP_at_2:240/5889 meinte am 31.07.95 zum Thema "Compressed export to Tape":
crU> From: c9527_at_rrzc4.UUCP crU> crU> Hello, database backuppers, crU> has anyone an idea, how i can write the output of the UNIX-compress to a crU> DAT-Tape without first writing it to a file (which would be larger than crU> the free space on my harddisks)?
It is a problem of the implementation of the LZW-algorithm used by the compress command. compress (on our hp-ux) used varying alphabets for compression from 9 to 15 bit length. So it would have to rewrite the tape when changing the length of the alphabet. We were recently told - facing a similar problem - to use tape drives with hardware compression. That's far better and more safe (and faster too).
If anyone has a better idea (like your named pipes) please let me know!
Kind regards
Dirk Breuer Received on Mon Aug 07 1995 - 00:00:00 CEST