In this case a log transaction is created containing all of the split
nodes as physical updates and possibly some merged nodes from the free
tree. Btree splitting can always be committed atomically and
independently of any other activity on the filesystem. It is nicely
bounded by the btree depth. Allocations that do not require splitting
the free tree are logged logically, leaving the affected free tree
blocks dirty in cache. So the allocation updates come "for free",
being tucked into the same commit block that governs the split btree
I now see how UNDO works, thankyou for your patient explanations. The
point I overlooked is, fsync (and friends) is indeed the only barrier
you have to worry about.
Still, I think it is good to try to get as much as possible of what was
going on in a bit burst of activity with no fsync durably onto disk.
Redo will clearly leave the filesystem in a consistent state less far
back in time than undo.
So my general strategy is to log big changes like splits as "physical"
full block updates and small ones like allocating an extent as logical
edit records in the commit blocks of the physical updates.
The complexity you noted above is due to making sure that the on-disk
image of a block is always what the logical edit record expects it
Yes, allocate-in-free is usually nasty. I need to ensure that there is
always a reserve of blocks available on disk that is more than the
maximum possible transaction that can be accepted. This simple idea
can get really complex, I know. One nice trick to simplify things a
little is to have a really generous limit on the maximum number of
dirty blocks that are allowed, when the filesystem has lots of free
space, and shrink that limit progressively as free space approaches
zero.
I now see what you were driving at with your point about interlocking
namespace transactions, etc. While each VFS transaction can indeed be
committed on its own, atomically and independently, to do so would be
death for throughpu...
