From: Takahiro Yasui <tyasui@redhat.com>
To: agk@redhat.com
Cc: device-mapper development <dm-devel@redhat.com>
Subject: [RFC] Redundant LVM mirror log
Date: Thu, 16 Jul 2009 15:55:31 -0400 [thread overview]
Message-ID: <4A5F85B3.1080906@redhat.com> (raw)
Hi,
I would like to solve an issue that LVM mirror can use only one
mirror log. I hope this post would start good discussion and go
forward to solve it.
ISSUES
======
Current implementation allows LVM mirror to use only one log disk.
A log disk keeps a bitmap and a each bit in the bitmaps shows the
status (in-sync or out-of-sync) of a region among mirror legs.
When a mirror is activated, log disk is checked and the data in the
out-of-sync region is copied from primary mirror device to others.
However, once a log disk gets broken, and the data in the log disk
can not be read, data replications for a whole disk are required
when the mirror is activated since LVM mirror (dm-mirror) can not
decide which regions are in-sync.
If mirror disk size is huge, it takes long time for disk replication,
and it utilizes much system resources, such as I/O bandwidth, CPU,
memory. That would cause system performance degradation until disk
replication completes. A log disk failure at boot is highly possible,
and the whole disk replication should be avoided.
PROPOSED APPROACH
=================
We have discussed two approaches to configure more than one log
disk so far.
- dm-log: support multi-log devices
https://www.redhat.com/archives/dm-devel/2008-November/msg00113.html
- lvm2: mirroredlog support (posted by malahal)
https://www.redhat.com/archives/dm-devel/2008-December/msg00095.html
The first approach, multi-log, is a kernel side approach and can
do quick disk blockage inside the kernel, while mirroredlog uses
current mirroring feature and constructs a log disk as a mirrored
disk.
I think that the mirroredlog approach is a quick and easy way to
achieve redundant mirror log. I would like to proceed the mirroredlog
approach so that it is merged into upstream.
I appreciate your comments.
Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America) Inc.
reply other threads:[~2009-07-16 19:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4A5F85B3.1080906@redhat.com \
--to=tyasui@redhat.com \
--cc=agk@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.