home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / linux / 25664 < prev    next >
Encoding:
Text File  |  1993-01-28  |  1.4 KB  |  35 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!think.com!spool.mu.edu!darwin.sura.net!haven.umd.edu!wam.umd.edu!joel
  3. From: joel@wam.umd.edu (Joel M. Hoffman)
  4. Subject: Re: [Q] Compressed Filesystem? Interest?
  5. Message-ID: <1993Jan26.233155.3936@wam.umd.edu>
  6. Sender: usenet@wam.umd.edu (USENET News system)
  7. Nntp-Posting-Host: rac2.wam.umd.edu
  8. Organization: University of Maryland, College Park
  9. References: <1993Jan20.213854.5028@sfu.ca> <1993Jan20.221858.1962@wam.umd.edu> <2B5EB4A9.1B6D@tct.com>
  10. Date: Tue, 26 Jan 1993 23:31:55 GMT
  11. Lines: 22
  12.  
  13. In article <2B5EB4A9.1B6D@tct.com> chip@tct.com (Chip Salzenberg) writes:
  14. >According to joel@wam.umd.edu (Joel M. Hoffman):
  15. >>The idea is that the anti-compressed file system would work in tandem
  16. >>with an ordinary file system.  For most uses, you would mount the
  17. >>system as, say xfs.  But for backup purposes, you would umount the xfs
  18. >>system, and remount >the same disk partition< as xfs-anti-compress.
  19. >
  20. >I think a better idea is to make compress capable of compressing many
  21. >files with one invocation -- producing an output stream that looks
  22. >something like, say, an afio archive, which is then process by tar in
  23. >lieu of reading the actual files -- thus avoiding process-per-file
  24. >overhead and staying out of the kernel.
  25.  
  26. But then you have the problem that a corruption of one file will
  27. corrupt following ones.  You may as well just 
  28.  
  29.     tar | compress | tar +multi-volume
  30.  
  31. -Joel
  32. (joel@wam.umd.edu)
  33.  
  34.  
  35.