If one breaks backwards compatibility for a crash during the resize
operation (which sounds perfectly fine to me), though, this could all be
done without a transaction with atomic file system updates.
How does this plan sound?
1. Move the log to the area we're growing into.
2. Change file system size. If we can't grow it to the desired size, grow
it as much as possible.
3. Traverse the file system and move things out of the way for the desired
bitmap and log size. A 512 block log with 1024 byte block size would
leave enough space to grow the volume 4 GB, which should be plenty for
even the most extreme resize.
4. Move the log back and grow the volume to the desired size if we
couldn't before.
This way the non-standardness is isolated to the log position, which
sounds rather manageable to me.
