On 16.07.2012 15:09, Andreas Henriksson wrote:
How about the following: ...Hm. This way it would essentially work as a swap space while creating the new bitmap. There'd still be a problem with fitting the new bitmap in a big resize transaction, since having the bitmap anywhere but the beginning is not a valid state for the file system. Moving the log area would also be necessary, otherwise it will be overwritten while replaying the journal as it is located right after the bitmap.
It would indeed open a can of worms. 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.
For example, you could use new constants for the disk_super_block::flags field to store the state. Previous BFS versions should then simply not be able to mount a file system that crashed during resize. A read-only file system should not mind at all if it cannot use the block bitmap.
The file system would just need to know the state it was in during the crash.
Bye, Axel.
