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 ⮂ View original 1980s typography