home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / question / 15127 < prev    next >
Encoding:
Internet Message Format  |  1993-01-03  |  1.7 KB
  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!ccsis
  2. From: ccsis@sunlab1.bath.ac.uk (Icarus Sparry)
  3. Newsgroups: comp.unix.questions
  4. Subject: Re: Pipe cpio output through compress?
  5. Message-ID: <C0AFLK.9xI@sunlab1.bath.ac.uk>
  6. Date: 3 Jan 93 17:09:43 GMT
  7. References: <wZ9RwB3w164w@cellar.org>
  8. Organization: Bath University Computing Services, UK
  9. Lines: 27
  10.  
  11. In the referenced article, toad@cellar.org (Tony Shepps) writes:
  12. >Would this be a suitable and cheap way to get compression on tape backups?
  13. >
  14. >  # find . -print | cpio -ocv | compress >/dev/rmt/(tape device)
  15.  
  16. Depends on the device driver for the tape device. If I were doing it I would
  17. use 'dd' to package up the output.
  18. e.g.
  19.  
  20. find . -print | cpio -ocv | compress | dd 'of=/dev/rmt/(tape device)' 'obs=60k'
  21.  
  22. If you don't use 'dd' then you get two effects.
  23. 1) The size of the blocks which you pass to the device driver may vary in
  24. size. Not a major problem but it can make reading them back a little difficult
  25. if your program is not written to expect differing size blocks. Also some
  26. primate device drivers get upset if you are not writing a multiple of 512
  27. bytes to a block device.
  28.  
  29. 2) For typical tape devices you would not get anywhere near as much on a
  30. tape as you would expect due to 'inter block records' A tape drive wants
  31. to be able to start the motor, read the data, then stop the tape in order
  32. to read the block. The starting and stopping tape a finite amount of time,
  33. and therefore a finite amount of tape. If you only write a few hundred
  34. bytes, then the 'wasted' tape is much longer than the useful tape. Therefore
  35. if one could, one would like to write say a megabyte at a time. Unfortunately
  36. some systems are not able to process an I/O request for more than 64k at
  37. a time, hence the '60k' parameter.
  38.