[haiku-commits] Re: BRANCH ahenriksson-github.production - src/add-ons/kernel/file_systems/bfs
- From: Andreas Henriksson <sausageboy@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 12 Jul 2012 22:19:58 +0200
> Also, resizing the block bitmap probably cannot be done in a single
> transaction, as the log might be too small, or in a transaction at all,
> since the log area might interfere.
Isn't resizing the block bitmap just a matter of zeroing blocks and
changing the size in the superblock? The log area is supposed to have been
moved away when it happens.
> BTW, how do you solve that the block bitmap is used, but must not
> overwrite existing data at the same time?
I don't understand this question. That probably means that I don't solve
it. :)
> I guess that is just a matter of updating the parent?
Yeah, I realized that I hadn't gotten around to that when I saw the
Start() flags.
> How would that work in this direction? How to move the journal before
> having made space for it by moving away inodes?
> Or are these just leftovers? :-)
The "//do resize" refers to updating the disk size in the superblock. The
file-system-travsersing-moving-stuff is done before the journal is moved.
Actually, I realize now that there's a big mistake in the code, fEndBlock
is supposed to be the old end when we're growing the disk, not the new.
> While that is true in theory, it's probably not too much to ask for a
> clean disk before resizing (ie. letting the user call checkfs in case of
> errors).
Indeed, I suppose I went a little overboard with that one.
> Doing it twice is twice as much fun?
Making sure the parent is really, really updated. :)
> What does the temporary mean?
A quick copy-paste from DeviceOpener to try things out, it should probably
live in Volume.
> aTODO? :-)
It's short for "Andreas, grep for this and fix it before you push your
code!". The previous constructor definition is another perfect example. :)
//Andreas
Other related posts:
