home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compress / 4523 < prev    next >
Encoding:
Text File  |  1993-01-10  |  2.0 KB  |  43 lines
  1. Newsgroups: comp.compression
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!rogerj
  3. From: rogerj@aix.rpi.edu (Diversion (Jeff Rogers))
  4. Subject: An idea for HD compression
  5. Message-ID: <+7_3k_+@rpi.edu>
  6. Nntp-Posting-Host: aix.rpi.edu
  7. Date: Sun, 10 Jan 1993 19:16:11 GMT
  8. Lines: 33
  9.  
  10. I came up with idea a few days ago; I don't know if it's been suggested
  11. before.
  12.  
  13. On a hard disk, files take up integral multiples of sector sizes. (Unless
  14. the filesystem packs them together, but I don't think too many do that).
  15. This means that many files will waste disk space on their last sector. On
  16. average, each file will waste half of it's highest sector. Under messy-dos,
  17. this translates (If I remember ny ms-dos internals correctly) to a waste of
  18. about 1K per file. (1024 byte sectors, 2 sector clusters). On a resonable
  19. sized hard disk, this could mean a good deal of space. With 4000 files (not
  20. too unreasonable), this means a waste of almost 4 megs. 
  21.  
  22. Why not try to reclaim this lost space? Use a null-suppression algorithm on
  23. half-empty sectors, keep an index of them, store them somewhere else in a
  24. packed form, and get them when they're requested by int 13(?). 
  25. As an extension of this, use a more elaborate compression scheme (LZ7x) and
  26. compress all sectors. 
  27. I think this is similar to what stacker does, but I recall hearing that
  28. stacker operates on ms-dos files only, and doesn't work with other os's
  29. (including the hardware version). (My information might be wrong.) This
  30. would be an alternative to stacker, and os transparent (assuming the os
  31. reads the disk thru int 13, and not some ultra-low-level mumbo-jumbo).
  32.  
  33. Is this type of thing possible? Feasable? worthwhile? copyright
  34. infringement? (I'm not too sure about stacker stuff, I'm sure lots of people
  35. will enlighten me ;-) )
  36.  
  37. Diversion
  38.  
  39. -- 
  40. "I can see 'em                          | "Want me to create a diversion?"
  41.     I can see 'em                       | Diversion
  42.         Someone wake me when it's over" | rogerj@rpi.edu
  43.