home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9481 < prev    next >
Encoding:
Text File  |  1992-08-31  |  2.2 KB  |  52 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!math.fu-berlin.de!news.uni-stuttgart.de!ifi!news
  3. From: weberj@dia.informatik.uni-stuttgart.de (Weber)
  4. Subject: Re: Stacker like file system
  5. Message-ID: <1992Aug31.124612.1328@ifi.informatik.uni-stuttgart.de>
  6. Summary: A way to do it ? 
  7. Sender: news@informatik.uni-stuttgart.de
  8. Organization: Informatik, Uni Stuttgart, W.Germany
  9. References: <1992Aug28.075627.13395@infko.uucp> <BtpF3M.2xn.2@cs.cmu.edu>
  10. Date: Mon, 31 Aug 1992 12:46:12 GMT
  11. Lines: 39
  12.  
  13. I think there is a way to implement a stacker like file
  14. system without having to change much of the kernel.
  15.  
  16. Hook the low-level routines for reading/writing one block
  17. from/to disk and insert a compression algorithm between.
  18.  
  19.  natural-size  -----> compression ----> compressed block
  20.                <----- decompression <--
  21.  
  22. For (de)compression use the LZW algorithm with variable size
  23. (look at the sources of compress to learn how to do it). If 
  24. you use block sizes of 4K it should be easier as in compress
  25. as you don't have to recycle codes (every block is done inde-
  26. pendently so a code table of 4K is always enough for a block of 4K).
  27.  
  28. I think the main problem in doing this is that the compressed
  29. blocks have a "random" size <= 4K and you encounter the same
  30. problems as with memory management. To write you have to look
  31. for a fitting free space on the free list by doing some of the
  32. XXX-fit strategies. If there is not enough free space at one
  33. continuous location you even may have to do a kind of garbage 
  34. collection.
  35. Initially each block has a "not yet written" flag. On second 
  36. write the old location is added to the free list again (and 
  37. merged with neighboring free blocks if possible).
  38. Blocks that can't be compressed should be written unchanged.
  39. Reading should be easy. Just look up its position in a Block
  40. Allocation Table (an array of pointers to compressed blocks).
  41.  
  42. But what should df tell? I think the double of the physical
  43. amount. But there may be problems with blocks that can be 
  44. compressed not or only little (e.g. *.Z). I think superstore
  45. signals a write protect error if the superstore partition is
  46. full ? 
  47. -- 
  48.  
  49. Juergen G. Weber
  50. Student am Institut fuer Informatik
  51. Universitaet Stuttgart - Germany
  52.