On 16.07.2012 18:33, Andreas Henriksson wrote:
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.
I think that sounds actually more complicated than using a temporary second bitmap instead, especially because you still might have to resize iteratively. At least I don't see what makes this approach better. You save copying the bitmap over, but the rest will be more complicated in return.
Bye, Axel.