THE MYSTERIOUS CASE OF 'FREE' SPACE BECOMING 'USED'
                   by Eugene and Vladimir Volokh, VESOFT
 Published by WHAT'S UP DOCumentation, Robelle's Newsletter, Mar 1995.


    Once upon a time (in July of 1988, to be exact) there was a
  question in INTERACT about a file with the record size of one
  sector, EOF=529 but the size in sectors 300. "Is this some super
  compression algorithm HP is using?  Can I make all my files this
  small?" -- the user asked.

    This question was answered (by VESOFT): it appears that MPE
  might create "holey" files, i.e. files with some extents inside the
  files not allocated, because records were not written there yet.
  There is some interesting "feature" of such files...

      For the inquisitive MPE/iX user who cares about managing disc
  space -- and who shouldn't? -- we propose the following:

      First, let's build a file (and, as always, call it X)

  :build X
  :listf X,2

  ACCOUNT=  VESOFT      GROUP=  PUB
  FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                    SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
  X                 128W  FB           0       1023   1        0  0  *

      As we can see, the file is empty -- EOF=0, SECTORS=0 (even though
  there is, somewhere, some space occupied by the file label), #X=0
  (eXtents given to the file); MX=* means that the MPE/iX file system
  has not set the Maximum eXtents number.

      Now, let's write some information to this file -- not sequentially
  starting from the beginning, but directly (by record number).  Maybe
  your application is working this way already...  For the purpose of
  this exercise,  we can use MPEX's handy file I/O functions

  :main.pub.vesoft 'calc vefwritedir("X,old;acc=inout","LAST",1022)'
  :listf X,2

  ACCOUNT=  VESOFT      GROUP=  PUB
  FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                    SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
  X                 128W  FB        1023       1023   1      256  1  *

  We've written only one -- but the last -- record to this file and
  see what has happened: the end of file is equal to the file limit
  (which does NOT mean that X is full!) and one extent of 256 sectors
  becomes part of the file.

      And now, the most interesting fact -- let's just read (not write!)
  our file X by simply :PRINTing it (try also :FCOPY or :EDITOR)

  :print x>$null
  :listf X,2

  ACCOUNT=  VESOFT      GROUP=  PUB
  FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                    SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
  X                 128W  FB        1023       1023   1     1024  4  *

      Note the final number of sectors and number of extents: there are
  FOUR extents allocated to the file and they take a whopping 1024 secto
  Just imagine how much space can be moved from 'free' to 'in use' if you
  have on your HP3000 more files like that with more and bigger holes...
  Try this on an MPE/V box and you'll get a different result (which is
  the one you probably expected to begin with).

  And check your system using MPEX's command
  %LISTF @.@.@(isfixed and recsize*eof/256>sectors),2

Go to Adager's index of technical papers