Hi,
We currently have 64 bits left over in the gfs2 metadata header. This is
currently just padding, although we do zero it out when we add metadata
blocks to transactions. I would like to ensure that we make the most of
this space, and I've got a couple of ideas of how best to use it.
Firstly, we should be able to add checksums to our metadata quite
easily. A crc32 would use half of the space available, and we should
probably do the checksum at the point where we write the data into the
log, so that it is then also correct for when it is written back in place.
The more tricky issue is what to do with the remaining 32 bits. One
thought, is to come up with some scheme which (eventually) allows us to
avoid having to write out revokes to the log. This would significantly
speed up moving glocks from node to node, halving the number of log
flushes when metadata has been updated. We could make it into a
generation number, but is 32 bits enough? By incrementing it
individually on each bit of metadata each time it goes through the log,
we would get a better picture of whats going on, rather than just
copying the low 32 bits of the log sequence number I think. That should
be enough to make sure that we'd keep out of trouble even if someone is
using a large (non-default) log size.
The question is whether there is anything else we might use those 32
bits for that might give us an even bigger gain? Any thoughts?
I should mention that this is all for metadata - we'd have to do
something different for jdata, since it doesn't have a header in this
sense, but, one thing at a time!
Steve.
