[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] Re: [RFC] [PATCH] lvm2: mirroredlog support

malahal us ibm com wrote:
> Takahiro Yasui [tyasui redhat com] wrote:
> ...
>> When one of log disk is broken and is not recognized, there is a case
>> disk that replication is executed. Let me explain with the following
>> simple case, which is the mirror volume, vg00-lv00 is composed of two
>> data disks and one mirrored log which is composed of two log disks.
>> * Analysis of this problem
>> A mirrored log is a type of "core" log and log devices need to be
>> synchronized when a mirrored log is activated. But when the first log
>> device is not recognized, "READ" I/O returns -EIO in disk_resume()
>> because log disk is not in-sync status and a default log can not be
>> switched to the other log disk working well.
>> Avoiding disk replication even if a log device got trouble is one of
>> the requirements. Is there any solution to avoid this problem by the
>> mirrored log approach?
> Two ways to fix:
> 1) Never make "error leg" as your master leg as that is pointless.

This approach will solve the case that a log leg is not recognized, but
I'm afraid that it won't solve other type of I/O errors, such as medium

LVM commands such as vgchange accesses only sectors containing label and
metadata, and LVM commands will successfully activate mirrored log as a
userland process. However, in kernel, I/Os errors might be detected in
a log area, and "READ" I/O returns -EIO. In this case, log will be detected
as a failed device.

> 2) Maybe we can use 'nosync' option when one of the two legs is known to
>    be an error device. This is probably easier than method (1)

This approach looks good.

Takahiro Yasui
Hitachi Computer Products (America), Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]