archive mirror
 help / color / mirror / Atom feed
From: "heming.zhao" <>
To: David Teigland <>
Cc:, Zdenek Kabelac <>
Subject: Re: [linux-lvm] [PATCH] lib/metadata: add new api lv_is_available()
Date: Tue, 1 Sep 2020 17:09:23 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 9/1/20 6:37 AM, David Teigland wrote:
> On Sun, Aug 30, 2020 at 11:49:38PM +0800, 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.
'broken' is acceptable and good word.
I'm only afraid end user don't know there is a new string item for lvs.
like me, I just know the lv_health_status string item from Zdenek's mail. (sorry for my stupid)

>> 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.)
I prefer lvm report status from the entire LV side.
lvm provides virtual blocks to upper layer softwares, most of softwares use whole virtual disk.
there must have some scenarios which lvm doesn't know LV status accurately.

there is example about lvm doesn't know LV status. (it's very like other modules bug not lvm problem)
if removing one of raidX sub-disks then do re-insert, the lvs will report LV work normally.
But from my env, I saw the re-inserted disk major:minor was changed. The device-mapper table still
keep old major:minor mapping, LV r/w io will send no-exist disk and trigger r/w error.
So if we want to report LV status accurately, the code should do a lot of works, like verifying DM table
mapping, verifying underlying devs, verifying raid level limit, ...

>> 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

  reply	other threads:[~2020-09-01  9:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 16:05 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
2020-09-01  9:09         ` heming.zhao [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [linux-lvm] [PATCH] lib/metadata: add new api lv_is_available()' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).