From: Phillip Susi <psusi@cfl.rr.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: [RFC][PATCH 0/4] dm-log: support multi-log devices
Date: Mon, 1 Dec 2008 11:10:01 -0500 [thread overview]
Message-ID: <49340C59.4070504@cfl.rr.com> (raw)
In-Reply-To: <49338BA6.3010809@redhat.com>
Takahiro Yasui wrote:
> 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.
Once the IO request has been completed, the data needs to be stable on
the disk. This means that either you have to wait until the data has
been written to all underlying mirror devices before completing the
request ( slow ) or you have to have some way of knowing which disk(s)
got written to, and which ones need updated after a crash. Are you
saying you take the former path?
> 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.
Does the entire log-data-log update cycle complete before dm completes
the higher level IO request? That would maintain data integrity, but at
significant cost to performance.
For performance sake, don't you want to allow write requests to be
completed before the log is necessarily marked as clean again? That way
multiple writes to the same data zone do not require multiple log
dirty/clean updates. Also for performance reasons, don't you want to
allow the data to be written to only one mirror before completing the
request? Then go back and do lazy synchronization?
next prev parent reply other threads:[~2008-12-01 16:10 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
2008-12-01 16:10 ` Phillip Susi [this message]
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=49340C59.4070504@cfl.rr.com \
--to=psusi@cfl.rr.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.