futures.doc

   1
   2 Future ideas for LaFS
   3 Things worth exploring, but not on the immediate horizon.
   4
   5 - Make sure all data structures are versioned.  This allows
   6   more experimentation.
   7
   8 - Duplicate all metadata blocks and include a checksum in the index.
   9   This means that an index block stores:
  10     fileaddr  phys1   phys2   checksum.
  11
  12   If phys1 cannot be read or doesn't match checksum, try phys2.
  13   Need to figure how best to write second copy at some distance
  14   efficiently.
  15
  16   Also, indirect blocks would need a version that stored an array of
  17     phys1 phys2 checksum.
  18   Maybe just use same format as checksumed-index blocks so sparse directories
  19   are handled well.
  20
  21 - If top bit of 'phys' is set, then the address is that of a cluster header.
  22   Read that to find the data.  It could be a miniblock for a tail, or it
  23   could be compressed.
  24
  25 - non-logged files without non-logged segments.
  26   These do not benefit from snapshots or from better management of RAID4
  27   But could have advantages.
  28
  29   Possibly do a non-logged write if old location is more recent than
  30   most recent snapshot.
  31
  32 - Single-block segments.
  33   The segment usage counter would be one bit - plus error info.
  34   So make it 32 (16?) bits to cover all snapshots, and have 2 bits
  35   for error flags?
  36
  37   Could use these only for cleaned data if the level-0 device is
  38   NVRAM or similar.
  39
  40   Could have a different cluster header that explicitly lists all
  41   physical blocks.  Possibly use compression to use only a couple of bytes most of the time.