geom_mirror delayed synchronizing question

[Deomid Ryabkov]

R. B. Riddick wrote:
> I would be glad if it was possible for gmirror to detect an idle
> gmirror-device... If it is idle, requests r issued more frequent and if the
> device experiences concurrent requests (e. g. from fsck), gmirror does no or
> hardly any sync requests...
>   
i had somewhat different idea of making a kind-of lazy resync but with 
bounded time to recovery.
the thing is that on a busy system there's a lot of i/o going on, so we 
can piggy-back our recovery on that.
e.g., as we read blocks, we copy them to the out-of-sync components.
the way we bound our recovery time is we say, ok, i want the mirror 
synced in X hours (a sysctl) and we then keep track of how many
blocks our lazy resync yields. for example, each minute we evaluate how 
many blocks we have resynced lazily and, with the target time of recovery,
how many we are missing. we then schedule the difference to be resynced 
(e.g., with N blocks and X hours of target resync time, we should resync 
N/X/60 blocks every minute,
so if lazy resync does not resync enough blocks, we read and resync them 
directly).
the drawback is that this would necessitate keeping a bitmap of resynced 
blocks, but the size is manageable with blocks of, say, 64k.
the map can be discarded when resync is complete.
> But this strategy could lead to a very very lengthly rebuild process on a very
> busy server, which contracts a RAID0-like risk of (complete) device failure...
>
> Maybe this "nice feature" should be implemented somehow intelligently? Maybe
> phases of rebuild and phases where concurrent user-land requests r executed?
> E. g.: 10 second undisturbed user-land (if there r any pending requests) and
> then 1 second gmirror's rebuild requests...
>   
might work as well. again, these numbers can be calculated from the 
target resync time.

-- 
Deomid Ryabkov aka Rojer
myself at rojer.pp.ru
rojer at sysadmins.ru
ICQ: 8025844