[haiku-commits] Re: BRANCH ahenriksson-github.production - src/add-ons/kernel/file_systems/bfs

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 16 Jul 2012 17:09:07 +0200

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.

AFAICT all that is needed is a flag in the super block indicating that the 
block bitmap is at the end of the partition. It would be set in the super block 
as soon as the complete block bitmap has been copied. I don't see a reason why 
copying the block bitmap would have to happen in a transaction. All that is 
needed is a synchronization point when both block bitmaps are identical (up to 
the old size that is) and no transactions are pending. At that point the switch 
to the new block bitmap can happen atomically together with setting the new FS 
size. During the copying phase the block allocator probably needs to write 
changes to both block bitmaps, so they don't got out of sync. Moving the block 
bitmap back to the original position would happen analogously. Moving the log 
is even more simple, since after the blocks have been reserved and the log has 
been flushed one can simply update its location in the superblock.

The only drawback I see is that the new flag -- i.e. the block bitmap at the 
end state -- would not be supported by older versions of the BFS module. But 
since that is supposed to be a temporary state (i.e. only encountered when the 
resize operation was interrupted), I would consider that acceptable. At least 
much better than not being able to resize a full FS at all.

CU, Ingo

Other related posts: