From: David Teigland <teigland@redhat.com>
To: Nir Soffer <nsoffer@redhat.com>
Cc: Ingo Franzki <ifranzki@linux.ibm.com>,
LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size
Date: Tue, 5 Mar 2019 10:36:31 -0600 [thread overview]
Message-ID: <20190305163631.GD1155@redhat.com> (raw)
In-Reply-To: <CAMRbyyvi=eqOAaj40WGSTS1+125dd+a=u8tyby6CHNpEOGVovw@mail.gmail.com>
On Tue, Mar 05, 2019 at 06:29:31PM +0200, Nir Soffer wrote:
> I don't this way of thinking is useful. If we go in this way, then write()
> should not
> let you write data, and later maybe the disk controller should avoid this?
>
> LVM is not a low level tool like dd. It is high level tool for managing
> device mapper,
> and providing high level tools to create user level abstractions. We can
> expect it
> to prevent system administrator from doing the wrong thing.
>
> Maybe LVM should let you mix PVs with different logical block size, but it
> should
> require --force.
>
> David, what do you think?
LVM needs to fix this, your solution sounds like the right one.
next prev parent reply other threads:[~2019-03-05 16:36 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 15:33 [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size Ingo Franzki
2019-02-27 0:00 ` Cesare Leonardi
2019-02-27 8:49 ` Ingo Franzki
2019-02-27 14:59 ` Stuart D. Gathman
2019-02-27 17:05 ` Ingo Franzki
2019-03-02 1:37 ` L A Walsh
2019-02-28 1:31 ` Cesare Leonardi
2019-02-28 1:52 ` Stuart D. Gathman
2019-02-28 8:41 ` Ingo Franzki
2019-02-28 9:48 ` Ilia Zykov
2019-02-28 10:10 ` Ingo Franzki
2019-02-28 10:41 ` Ilia Zykov
2019-02-28 10:50 ` Ilia Zykov
2019-02-28 13:13 ` Ilia Zykov
2019-03-01 1:24 ` Cesare Leonardi
2019-03-01 2:56 ` [linux-lvm] Filesystem corruption with LVM's pvmove onto a PVwith " Bernd Eckenfels
2019-03-01 8:00 ` Ingo Franzki
2019-03-01 3:41 ` [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with " Stuart D. Gathman
2019-03-01 7:59 ` Ingo Franzki
2019-03-01 8:05 ` Ingo Franzki
2019-03-02 1:36 ` Cesare Leonardi
2019-03-02 20:25 ` Nir Soffer
2019-03-04 22:45 ` Cesare Leonardi
2019-03-04 23:22 ` Nir Soffer
2019-03-05 7:54 ` Ingo Franzki
2019-03-04 9:12 ` Ingo Franzki
2019-03-04 22:10 ` Cesare Leonardi
2019-03-05 0:12 ` Stuart D. Gathman
2019-03-05 7:53 ` Ingo Franzki
2019-03-05 9:29 ` Ilia Zykov
2019-03-05 11:42 ` Ingo Franzki
2019-03-05 16:29 ` Nir Soffer
2019-03-05 16:36 ` David Teigland [this message]
2019-03-05 16:56 ` Stuart D. Gathman
2019-02-28 14:36 ` Ilia Zykov
2019-02-28 16:30 ` Ingo Franzki
2019-02-28 18:11 ` Ilia Zykov
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=20190305163631.GD1155@redhat.com \
--to=teigland@redhat.com \
--cc=ifranzki@linux.ibm.com \
--cc=linux-lvm@redhat.com \
--cc=nsoffer@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 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.