Re: DragonFly-2.3.1.868.g90eca master sbin/hammer cmd_expand.c s
:Yeah! But lets make expansion stable first. I think replacing the root
:volume can be quite tricky, as one has to move the layer1 array and has
:to take care that the undo log is correctly "moved" to another volume.
:Btw, is there a pointer to the undo log (i.e. can it be placed on
:any volume) or is the undo log implicitly assumed to be on the
:root-volume?
:
:When I expand a hammer filesystem, upon umount I still get the following
:message:
The undo log is on the volume marked as the root volume. The final
switch-over the root volume could be problematic. The vol_rootvol
field in the hammer_volume_ondisk structure has to be set the same
on all volumes.
: HAMMER: umount flushing......... giving up
It's possible you are generating too much UNDO without flushing
inbetween.
You may be able to trivially avoid generating too much undo with
a trick. You are generating undo for all your layer2 formatting,
but if layer2 previously did not contain any valid data then you
are not actually overwriting anything and you do not have to
generate undo for the layer2 updates.
I would experiment with that first. If it doesn't prevent the
flushing problems then add hammer_flusher_meta_halflimit() checks
in the layer1 loop as appropriate (similar to what is in
hammer_rebalance.c). Remember that everything must be unlocked
before you can call hammer_flusher_wait().
Unfortunately there might be an issue with the layer1 formatting
as well. You have to write out undo for that, and if you flush
in the middle there will be a partially activated volume in the
filesystem even though the entire formatting has not been completed.
If that case occurs you have to detect the condition where the
volume has already been added, skip the bits already formatted,
and continue formatting from where you left off. You can do this
by testing whether the related layer1 entry has already been formatted
or not (since if it hasn't it will be marked as HAMMER_BLOCKMAP_UNAVAIL).
Another possibility is that you are forgetting to unlock something,
but so far as I can tell the locking looks ok.
:Right now, I split the layer1/layer2 formatting into two steps.
:At first I format layer2 (using bread/bwrite), then after the call to
:hammer_install_volume() I do all the layer1 formatting using
:hammer_bread (for current hard disks this is just one entry) etc.
:
:Do you think it makes sense to do all the formatting using hammer_xxx
:functions? I think it is easier to not split the layer1/layer2
:formatting into two steps.
:
:Regards,
:
: Michael
If the volume is live... that is, it is connected to the mount,
then layer2 must be formatted first and layer1 last as the
layer2 buffer will become addressable the moment the related layer1
entry is formatted.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 5 之 7 篇)：