Re: DragonFly-2.3.1.868.g90eca master sbin/hammer cmd_expand.c s
Matthew Dillon schrieb:
> :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 did that in the first "version", where I used bread() functions to
completely format layer2 entries while the volume was offline and only
wrote layer1 entry/entries while online. Despite not generating many
UNDOs (exactly one for one layer1 entry) the "umount flushing" issue
appeared.
> 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().
Will try this approach.
> 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.
In case of a failure? Sure, but its not critical, as no data loss will
happen. Its easy enough to "release" the volume (once this is
implemented) and retry again.
When formatting layer2 while the volume is online, I better
generate UNDOs for layer2 entries as well, otherwise really bad
things might happen, like layer1 is there but layer2 entries are
not initialized. And thats what I am doing.
The amount of data that I am writing is fairly small, approx. 8 MB
for a volume up to 4 TB in size (excluding UNDO record overheads),
so I don't think that this matters much.
> 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.
Exactly what I am doing.
Thanks! I'll try some flushing in-between writes. Hopefully this helps.
Regards,
Michael
討論串 (同標題文章)
完整討論串 (本文為第 6 之 7 篇)：