From: Roberto Fastec <roberto.fastec@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: [linux-lvm] LVM2 Metadata structure, extents ordering, metadata corruptions
Date: Tue, 27 Sep 2022 12:10:56 +0200 [thread overview]
Message-ID: <CADoUXWv+Po7pdhcAUk=JSwaDYJ2qp6B7aXm_djOuaOB0r9Usrw@mail.gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1534 bytes --]
Dear friends of the LVM mailing list
I suppose this question is for some real LVM2 guru or even developer
Here I kindly make three question with three premises
premises
1. I'm a total noob about LVM2 low level logic, so I'm sorry of the
questions will sound silly :-)
2. The following applies to a whole md RAID (in my example it will be a
RAID5 made of 4 drives 1TB each so useful available space more or less
2.7TB)
3. I assign whole those 2.7TB to one single PV and one single VG and one
single LV.
questions
1. Given the premise 3. The corresponding LVM2 metadata/tables are and will
be just a (allow me the term) "grid" "mapping that space" in an ordered
sequence to in the subsequent use (and filling) of the RAID space "just
mark" the used ones and the free ones? Or those grid cells will/could be in
a messed order ?
And explicitly I mean. In case of metadata corruption (always with respect
of premise 3.) , could we just generate a dummy metadata table with all the
extents marked as "used" in such a way that we can anyway access them
And can we expect to have them ordered?
2. Does it exist a sort of "fsck" for the LVM2 metadata ? We do technical
assistance and recently, specifically with those NAS devices that make use
of LVM2, we have experienced really easy metadata corruption in occurence
of just nothing or because of a electric power interruption (which is
really astonishing). We mean no drives failures , no bad SMARTs . Just
corruption from "nowhere" and "nocause"
Thank you for any hint
Robert
Fastec
[-- Attachment #1.2: Type: text/html, Size: 1909 bytes --]
[-- Attachment #2: Type: text/plain, Size: 202 bytes --]
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
next reply other threads:[~2022-09-29 7:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 10:10 Roberto Fastec [this message]
2022-09-29 10:52 ` [linux-lvm] LVM2 Metadata structure, extents ordering, metadata corruptions Zdenek Kabelac
2022-09-29 11:15 ` Roberto Fastec
2022-09-29 11:41 ` Zdenek Kabelac
2022-09-29 12:12 ` Roberto Fastec
2022-09-29 11:48 ` Gionatan Danti
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='CADoUXWv+Po7pdhcAUk=JSwaDYJ2qp6B7aXm_djOuaOB0r9Usrw@mail.gmail.com' \
--to=roberto.fastec@gmail.com \
--cc=linux-lvm@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 read-only IMAP folder(s) and NNTP newsgroup(s).