home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9401 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  3.0 KB
  1. Path: sparky!uunet!ogicse!usenet.coe.montana.edu!uakari.primate.wisc.edu!ames!news.hawaii.edu!spectra!oles
  2. From: oles@spectra (Shawn Oles)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Stacker like file system
  5. Message-ID: <1992Aug30.024915.24276@news.Hawaii.Edu>
  6. Date: 30 Aug 92 02:49:15 GMT
  7. Article-I.D.: news.1992Aug30.024915.24276
  8. References: <BtpF3M.2xn.2@cs.cmu.edu> <1992Aug28.223823.9755@uoft02.utoledo.edu>
  9. Sender: root@news.Hawaii.Edu (News Service)
  10. Organization: University of Hawaii, Dept. of Electrical Engineering
  11. Lines: 54
  12. Nntp-Posting-Host: spectra.eng.hawaii.edu
  13.  
  14. In article <1992Aug28.223823.9755@uoft02.utoledo.edu> billp@jupiter.cse.utoledo.edu (Bill Parquet) writes:
  15. >mfp+@CS.CMU.EDU (Michael Polis) writes:
  16. >: |> Having a /usr/compressed/pics directory with on-the-fly compression would be
  17. >: |> a dream come true.
  18. >: How about storing them as GIF's, which are inherently compressed using
  19. >: the LZW algorithm (the one used by compress).
  20. >
  21. >There's a few disadvantages to using GIF format.   Most namely is the
  22. >restriction to 256 colors.  
  23. >
  24. >What kind of compression technique do those
  25. >programs [stacker/doubledisk/etc] use? (Hopefully this isn't the start of
  26.  
  27. I am not sure about the other companies, but stacker is based on Stac Electronics
  28. QIC-122 compression standard which is briefly discussed in "The Data
  29. Compression Book" (Nelson, 91 pg 228).  Basically it uses a variant of the
  30. Ziv-Lempel Dictionary discussed in their 1978 paper and exploited by Welch
  31. in the algorithm LZW.  There are a wealth of books on data compression. Read
  32. the FAQ in comp.compression for more detail.
  33.  
  34. >a completely unrelated discussion) ... The only thing that I think gets 
  35. >really ugly about those programs if you have a file that contians a block
  36. >of zeros in the middle, then you have a program that fseeks to that block
  37. >and writes a block of random data over it.  The compression program has
  38. >to deal with expansion in the physical file size.
  39.  
  40. easy.  If blocks are compressed at the block level, as we have been discussing,
  41. the new block can be re-written in the middle of the file independently of ALL
  42. other blocks in the file; thus just the modified block, with its new size, is
  43. written.  This not as easy as a normal modify but is doable.
  44.  
  45. This does lead to a few problems, most notably, if the file system is full and
  46. the modified block size increases, it is possible that the file system
  47. will have to generate an "no space on device" type error message, which
  48. might break a few programs.  
  49.  
  50. One place where this worries me slightly, is what happens if 
  51. a) if the file system is full
  52. b) and the user deletes a file, which modifies the block containing the
  53.    files directory entry
  54. c) and the modified directory block expands (which is highly unlikely, but
  55.    possible)
  56.  
  57. if this occurs, then the user will not be able to remove the directory
  58. entry, and might lead to a corrupted file system.  
  59.  
  60. Anyway, the easy solution is just to panic("your screwed\n"); and recomend 
  61. a reformat. :)  This is a highly unlikely senario, but still bothers me.
  62.  
  63.  
  64. -shawn
  65. -- 
  66.  
  67. -shawn
  68.