[dm-devel] Desynchronizing dm-raid1
malahal at us.ibm.com
malahal at us.ibm.com
Thu Apr 3 14:21:54 UTC 2008
Heinz Mauelshagen [mauelshagen at redhat.com] wrote:
>
> [HM] md RAID456 and dm RAID45 don't have the raid1 problem, because
> they utilize stripe caches, hence tacking page copies. Application pages
> can change nonetheless vs. stripe cache pages.
I wish they didn't make copies of data pages for the sake of
performance! If they did make copies for all of their I/O, they don't
have this problem.
> > 4. make more region states.
> > --- If the region is in RH_DIRTY state and all writes drain, the state is
> > changed to RH_MAYBE_DIRTY. (we don't know if the region is synchronized or
> > not). The disk dirty flag is kept.
> > --- periodically (once in few minutes, so that it doesn't affect
> > performance much), the change all regions in RH_MAYBE_DIRTY state to
> > RH_CLEAN_CANDIDATE, then issue sync() on all filesystems. If, after the
> > sync(), the region is still in RH_CLEAN_CANDIDATE (i.e. it hasn't been
> > written during the sync()), it is moved to RH_CLEAN state and the on-disk
> > bit for the region is turned off.
>
> [HM] This is essentially one technical approach for my comment on 2. above.
> RH_MAYBE_DIRTY sounds superfluous at first glance, because when all writes
> to a region drained, we can set RH_CLEAN_CANDIDATE, run the sync() and check
> if that state persists in order to trigger the dirty log update.
I don't think the state RH_MAYBE_DIRTY is superfluous. If the region
state is RH_CLEAN_CANDIDATE after the sync(), that means no 'write'
happened since we set RH_CLEAN_CANDIDATE. If there was any write, the
region state would be 'RH_DIRTY' or 'RH_MAYBE_DIRTY'.
--Malahal.
More information about the dm-devel
mailing list