[Tux3] Design note: Metablocks

[Daniel Phillips]

The Tux3 disk superblock is now 96 bytes in size including magic number.  
Do we have any plans for the other 4000 bytes?  Yes: we will fill the 
bulk of the disksuper with pointers to "metablocks".  A metablock is 
like a superblock, except it is stored at some arbitrary place on the 
volume and it only contains data that may vary per delta commit.  Any 
fields that are set just once at mkfs time will remain in the normal 
disk superblock.

Metablocks are reserved in the allocation bitmap and distributed roughly 
evenly across the entire volume.  (We may not actually represent these 
allocations in otherwise empty bitmap blocks, to avoid creating 
hundreds of bitmap blocks at mkfs time.)

The notion of metablocks addresses three issues:

  * When a pointer to the beginning of the log chain must be stored,
    it can always be stored in a fairly nearby location.  In other
    words, if we have 500 metablocks, the maximum time required to
    seek to the closest one is 1/500th of the average seek time for
    a single spindle.

  * Atomic update: overwriting the superblock risks damaging the
    filesystem if the write is interrupted when partially completed.
    We avoid that by never choosing the last written metablock as
    the location for the next.

  * We avoid constantly overwriting the superblock, which might be
    beneficial for some flash devices.

The main benefit is avoiding seeking on delta commit.

On startup, a naive strategy is to search all the metablocks to find the 
most recently written.  A better strategy is to store the location of 
the most recently written metablock in a known location (e.g., the 
first or second metablock) and only search all the metablocks after an 
unplanned interruption, as determined by a flag set at a known 
location.

Metablocks themselves only need a few bytes of data each, maybe 100.  
The rest of a metablock may serve as an array of pointers to currently 
outstanding log blocks, in order to reduce the number seek time 
required to load all the log blocks at startup.

Except for the atomic update aspect, metablocks are purely an 
optimization for rotating media.  As such, we are in no hurry to 
implement them, which allows some time to refine the concept. 
Suggestions are welcome.

For now, to store a pointer to the most recent commit we will just 
mindlessly overwrite the disk superblock.  That will be inefficient 
(but not very) and risky (but not very).  It will do for now.

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3