Re: Desynchronizing dm-raid1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 03, 2008 at 07:21:54AM -0700, malahal@xxxxxxxxxx wrote:
> Heinz Mauelshagen [mauelshagen@xxxxxxxxxx] 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.

Me too but it's mandatory to be able to calculate parity chunks ;)

> 
> > > 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'.

Hrm, sound like a contradiction in your statement.
Either it stays RH_CLEAN_CANDIDATE because of no writes *or*
it's state-changing to RH_DIRTY, no ?

Heinz

> 
> --Malahal.
> 
> --
> dm-devel mailing list
> dm-devel@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux