> 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. //Andreas