From: David Teigland <teigland@redhat.com>
To: "heming.zhao@suse.com" <heming.zhao@suse.com>
Cc: linux-lvm@redhat.com, Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: [linux-lvm] [PATCH] lib/metadata: add new api lv_is_available()
Date: Mon, 31 Aug 2020 17:37:24 -0500 [thread overview]
Message-ID: <20200831223724.GB15486@redhat.com> (raw)
In-Reply-To: <4cce4f81-24b6-3730-a331-8b31cf57cd51@suse.com>
On Sun, Aug 30, 2020 at 11:49:38PM +0800, heming.zhao@suse.com wrote:
> in my opinion, the 'not available'
We already use the word available/unavailable in other ways, so let's use
"broken" for the moment, maybe we can find a better word.
'lvs -o broken' would report 0|1. Choosing an attr letter to represent
that is not as important and can be decided on later.
> means the LV can't correctly do r/w io.
>
> for raid, if the missing or breaking underlying devs number beyond raid level limit. the
> 'not available' shoud be display.
>
> for linear, any one of underlying dev is missing, upper layer module like fs may don't work
> (e.g. missing first disk, fs will missing w/r first disk's super-block metadata). the
> 'not available' should be display.
That definition of "broken" could be a specific enough, if we can report
it accurately enough. Do we need to say "io will succeed on the entire LV
(as far as lvm knows)"? It would be nice to know in which cases lvm can
report it accurately, and in which cases lvm doesn't know enough to report
it accurately. If it's not correct in many cases, then we should consider
a different definition (maybe raid-specific.)
> for other type LV, I don't have too much experience to answer this question.
Any LV not using raid (or mirror) will be equivalant to linear, and be
broken if a single disk is missing or broken.
Dave
next prev parent reply other threads:[~2020-08-31 22:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-27 16:05 [linux-lvm] [PATCH] lib/metadata: add new api lv_is_available() Zhao Heming
2020-08-27 16:07 ` heming.zhao
2020-08-28 16:04 ` Zdenek Kabelac
2020-08-28 18:26 ` David Teigland
2020-08-30 15:49 ` heming.zhao
2020-08-30 17:06 ` Zdenek Kabelac
2020-08-31 22:37 ` David Teigland [this message]
2020-09-01 9:09 ` heming.zhao
2020-09-01 15:07 ` David Teigland
2020-09-01 16:15 ` heming.zhao
2020-09-01 11:43 ` Zdenek Kabelac
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=20200831223724.GB15486@redhat.com \
--to=teigland@redhat.com \
--cc=heming.zhao@suse.com \
--cc=linux-lvm@redhat.com \
--cc=zkabelac@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).