From: Takahiro Yasui <tyasui@redhat.com>
To: malahal@us.ibm.com
Cc: dm-devel@redhat.com, agk@redhat.com
Subject: Re: [RFC][PATCH 0/4] dm-log: support multi-log devices
Date: Mon, 05 Jan 2009 10:44:27 -0500 [thread overview]
Message-ID: <49622ADB.7040200@redhat.com> (raw)
In-Reply-To: <20081223180228.GA24831@us.ibm.com>
Hi Malahal,
Sorry for my late reply.
malahal@us.ibm.com wrote:
> Takahiro Yasui [tyasui@redhat.com] wrote:
>> Hi Malahal,
>>> A while back IBM posted a patch to LVM that constructs a log device with
>>> a mirror and then creates the real mirror using such a mirrored log
>>> device. I think this may solve your problem. It was completely written
>>> in LVM and Stefan refreshed it to the latest LVM.
>> Thank you for the comment and information. It seems that your
>> approach seems to address my problem, too. Here I have a concern
>> about write performance because an additional mirror mapping might
>> introduce additional delay and overhead. In addition, error for
>> log devices is better to be handled by the simple way, and a basic
>> error handling would work.
>
> In theory yes, but I doubt it would be user visible that much. We expect
> transient failures under some circumstances, so we would like to handle
> them. In other words, a failed device is expected to come back and the
> mirror target should re-integrate it automatically when it comes back.
> Can your multi-log code handle re-synchronizing a log device?
my patch doesn't handle transient error now. I expect log devices
to be failed and got in a blockage status once an error has happened.
> With our user level only implementation, the log device handling would
> be as good as the real mirror *leg* handling. We get all the benefits of
> the mirror without doing any code! Wouldn't it be nice?
I agree that simple implementation is better, but log could be handled
without any additional layer, and also I'm thinking that log could be
handled in the simpler way.
Lower layer, such as SCSI, also has retry feature based on error type
and will be done in the proper way. Do you mean that it isn't enough
and should dm-layer handle errors for log device, too?
I introduced multi-log feature so that system can keep running even if
the lower layer could not recover errors.
Thanks,
Taka
next prev parent reply other threads:[~2009-01-05 15:44 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
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 [this message]
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=49622ADB.7040200@redhat.com \
--to=tyasui@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=malahal@us.ibm.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.