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@tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
