On Mon, 7 Apr 2008, malahal@xxxxxxxxxx wrote:
Heinz Mauelshagen [mauelshagen@xxxxxxxxxx] wrote:
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.
If I understand your above description: a region's state is set to
RH_DIRTY when an I/O is scheduled in the region and is set to
RH_CLEAN_CANDIDATE when all I/O is completed. In other words, a region's
state is RH_CLEAN_CANDIDATE when there is no pending I/O to that region.
Did I get it right so far?
Then we invoke sync(). Now, if the region's state is RH_CLEAN_CANDIDATE,
The problem is, that if sync() wrote to that region, it waits until all
writes drain and sets the region to RH_CLEAN_CANDIDATE too. So we couldn't
distinguish the cases, if the sync() wrote to the region or not.
During this sync() write, anyone else may modify the data too, so if the
sync() touched the region, we don't know if it's in-sync or isn't.
you set the region's state to RH_CLEAN. If the region's state is
anything other than RH_CLEAN_CANDIDATE, you don't do anything. Am I
correct?
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 ?
The state would be RH_CLEAN_CANDIDATE if there were ***NO*** writes as
part of sync(). The next statement only describes what would happen if
there were any writes as part of sync().
The sync() does write just like any other process, so it may create
RH_CLEAN_CANDIDATE state too. To check that the region was not written
during sync(), you need an extra state and make sure that no other code
sets this state, except your syncing thread.
Mikulas
--Malahal.
PS: Any comments from the original submitter if he thinks the state
is really superfluous?
--
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
