From: Takahiro Yasui <tyasui@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: Re: [RFC][PATCH 0/4] dm-log: support multi-log devices
Date: Tue, 02 Dec 2008 01:05:00 -0500 [thread overview]
Message-ID: <4934D00C.4030604@redhat.com> (raw)
In-Reply-To: <20081201110937.GA6287@rere.qmqm.pl>
Michał Mirosław wrote:
> 2008/12/1 Takahiro Yasui <tyasui@redhat.com>:
>> Phillip Susi wrote:
> [...]
>>> Right... and when recording a log on every disk in the mirror, each copy
>>> of the log may not contain exactly the same information at any given
>>> time. If you write to one disk in the mirror first, then you need to
>>> mark the region as dirty on that disk first, so that if the system
>>> crashes before you can copy the data to the other mirror, you can see
>>> that the first disk is more up to date than the second disk.
>>>
>>> In other words, knowing that a region is or is not synchronized across
>>> each disk is not enough; if they are out of sync you need to figure out
>>> which disk has the most current information so it can be replicated to
>>> the others, don't you?
>>>
>>> Or do you just always write to the first disk first, and assume it has
>>> the most recent data if the region was marked as dirty in ANY of the logs?
>> log disks are updated in parallel and we do not know which disk has the
>> latest and correct data if the system crashes during write operations
>> on log devices. But there is no problem about it.
>>
>> There are two cases we need to think about.
>>
>> 1) Some log devices contain "clean", but mirror devices are not synchronized
>>
>> This case is problematic, but never happens, because data is written on
>> mirror devices after marking log devices "dirty", and make it "clean"
>> after write I/Os on mirror devices completed and mirrors get synchronized.
>>
>> 2) Some log devices contain "dirty", but mirror devices are synchronized
>>
>> This case may happen but is not problematic. Just data replication of
>> the region among mirror devices will be done when the mirror is resumed.
>> This case would also happen on the system with the current single log if
>> the system crashes after marking a log device "dirty" and before marking
>> it back to "clean".
>
> What happens if some log devices contain "dirty" and not all mirrors were written
> yet before a crash? How do you know which mirror has the most recent data?
> Are the writes to mirrors ordered somehow?
What happens if it is a raw device rather than dm-mirror? The I/O has
not completed yet and the request has not returned to the upper layer.
If system crashed at this point, no one knows which data, new or old,
is on the device, and application such as database should be responsible
for the transaction if necessary.
In the situation on dm-mirror you asked, we do not know which mirror
has the latest data, but I think that it is not a problem.
Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America) Inc.
next prev parent reply other threads:[~2008-12-02 6:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 0:01 [RFC][PATCH 0/4] dm-log: support multi-log devices Takahiro Yasui
2008-11-26 18:56 ` Phillip Susi
2008-11-27 7:50 ` Takahiro Yasui
2008-11-28 20:06 ` Phillip Susi
2008-12-01 7:00 ` Takahiro Yasui
2008-12-01 11:09 ` Michał Mirosław
2008-12-02 6:05 ` Takahiro Yasui [this message]
2008-12-01 16:10 ` Phillip Susi
2008-12-02 4:52 ` Takahiro Yasui
2008-12-12 20:21 ` Jonathan Brassow
2008-12-15 14:56 ` Takahiro Yasui
2008-12-20 0:13 ` malahal
2008-12-23 0:23 ` Takahiro Yasui
2008-12-23 18:02 ` malahal
2008-12-31 20:15 ` malahal
2009-01-08 18:30 ` Jonathan Brassow
2009-01-08 19:00 ` malahal
2009-01-05 15:44 ` Takahiro Yasui
2009-01-05 16:24 ` malahal
2009-01-05 17:36 ` Takahiro Yasui
2009-01-05 18:44 ` malahal
2009-01-05 18:51 ` Alasdair G Kergon
2009-01-05 22:21 ` Takahiro Yasui
2009-01-05 22:26 ` Takahiro Yasui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4934D00C.4030604@redhat.com \
--to=tyasui@redhat.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.