[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 11:50:50 +0200
Andreas Henriksson wrote:
> > I guess you currently just require that there is enough free space to
> > move the nodes around?
>
> That's correct. I was thinking that it would be enough to ask the user to
> move some stuff to a different disk while resizing. That's not a very
> intuitive solution when it comes to the CD image though.
>
> On the other hand, I imagine that juggling a shadow bitmap overlapping the
> log and a transaction that might fill up with inodes, would get very
> complicated very quickly. My current opinion is that resizing in steps,
> either manually or automatically, is the best solution.
How about the following:
* Clone the block bitmap to the end of the partition with its new size.
* Perform the move operations to free enough space after the beginning of the
original block bitmap
* Copy the block bitmap back and free its clone.
The obvious requirement is that there must be enough new space for the cloned
bitmap plus the amount the old bitmap needs to grow. But if the FS size is
grown by more than current size/block size, that shouldn't be a problem. The
solution could be used as a fallback plan anyway, so that both conditions --
not enough space in the existing FS and not enough added space (i.e. something
like growing your full 1 TB FS by 100 MB) -- would need to hold to make the
resize operation fail.
I'm not familiar with the BFS on-disk structures. So maybe this is not possible
in a recoverable way should the resize operation be interrupted (crash/power
outage).
CU, Ingo
Other related posts: