gmirror State: STALE
Eric Anderson
anderson at centtech.com
Fri Jul 14 15:04:01 UTC 2006
On 07/14/06 07:15, R. B. Riddick wrote:
> --- Deomid Ryabkov <myself at rojer.pp.ru> wrote:
>> Pawel Jakub Dawidek wrote:
>>> BTW. Are you sure you don't want to use autosynchronization?
>>>
>> [...]
>> I think, that ultimately should be handled in the base system:
>> do not let mirror sync and fsck collide, ever.
>>
> I experienced the same problem... Especially when there are two mirrors on the
> same two disks... Somehow the head positioning times increase the overall
> processing time much more than linear...
>
> I think it would be a good idea to change the rebuild-strategy (maybe something
> that is slower; e. g. one rebuild-request per 20 other requests or when there
> are no pending other requests) in case of high load (e. g. fsck), although that
> would increase the risk of data loss (another strategy could be, that other
> requests are delayed until 20 rebuild-requests have been completed).
>
> There is another problem in my setting: The rebuild of the other mirror devices
> that use the same disk(s) should be delayed...
Maybe it's because the stale mirror disks are also trying to do reads
for the mirror provider? Maybe during mirror synch the out-of-date geom
should not participate in any reads? (Maybe that is how it is already -
I didn't look at the code) Maybe also mirror rebuilds should happen
'behind' the real writes - so when a block is written to the mirror, the
primary disk gets the data written in real-time and does not block
waiting for all the other mirrored geoms to finish writing also. That
way, if you have a slightly slower disk in a mirror, the slower disk
doesn't penalize the faster one. The cost of this is of course there
would be times during heavy IO that the mirror isn't *exactly* in sync.
Sounds like a good sysctl tunable? Maybe a maximum delay time setting
is the right choice, similar to what gjournal has. Maybe the same could
be achieved by setting:
kern.geom.mirror.syncs_per_sec: 1000
kern.geom.mirror.reqs_per_sync: 5
to something lower, like:
kern.geom.mirror.syncs_per_sec: 100
kern.geom.mirror.reqs_per_sync: 2
Or higher - I'm not sure how they would impact performance while an fsck
is running. Sounds like using your geom_cache on top of the mirror
would help this. :)
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
More information about the freebsd-geom
mailing list