linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: Andy Smith <andy@strugglers.net>
Cc: linux-lvm@lists.linux.dev
Subject: Re: Any way in LVM to deal with 512e vs 4Kn physical devices?
Date: Wed, 17 Jan 2024 12:48:32 +0100	[thread overview]
Message-ID: <b8913e84-6ec1-4c79-9ba7-baa7783c46ef@gmail.com> (raw)
In-Reply-To: <Zae4RzvB2EJxLf2W@mail.bitfolk.com>

Dne 17. 01. 24 v 12:21 Andy Smith napsal(a):
> Hi Zdenek,
> 
> On Wed, Jan 17, 2024 at 11:36:24AM +0100, Zdenek Kabelac wrote:
>> Lvm tool as such doesn't really have any problems with mixing 4K and 512b
>> disks within a single VG
> 
> That's interesting, though in my case I have done a block-based
> copy of an LV from a system where all PVs are 512b to one where all
> PVs are 4K.
> 
> So out of interest, what does LVM do when one PV within same VG says
> 512b and another says 4K - just pass on 512b for every LV I assume,
> unless allow_mixed_block_size is set as you mention?

lvm2 does nothing with disks.
How they are configured, that way they work.

There is nothing that would try to make 4K disks to be like 512b.

Although I believe there were some DM targets for such emulation built, but 
they are not upstream.

So if user had an old VG with mixed blocks created before protection was added 
to lvm2 -- they will continue to work with all the 'risks' - and lvm2 will 
show up some warnings here and there.

With new disks users are not allowed (by default) to mix them together with 
one VG.

Regards

Zdenek




  reply	other threads:[~2024-01-17 11:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15  7:30 Any way in LVM to deal with 512e vs 4Kn physical devices? Andy Smith
2024-01-15 21:07 ` Roger Heflin
2024-01-16 18:24 ` Phillip Susi
2024-01-16 20:13   ` Andy Smith
2024-01-17  7:22     ` Andy Smith
2024-01-17 12:13       ` Roger Heflin
2024-01-17 14:10       ` Phillip Susi
2024-01-20  4:45         ` Andy Smith
2024-01-20 18:00           ` Phillip Susi
2024-01-20 20:56             ` Andy Smith
2024-01-24 16:18               ` Phillip Susi
2024-01-24 21:17                 ` Roger Heflin
2024-01-25 19:05                   ` Phillip Susi
2024-01-17 14:06     ` Phillip Susi
2024-01-16 19:30 ` Ilia Zykov
2024-01-16 20:17   ` Andy Smith
2024-01-17 10:36     ` Zdenek Kabelac
2024-01-17 11:21       ` Andy Smith
2024-01-17 11:48         ` Zdenek Kabelac [this message]
2024-01-17 14:24   ` Phillip Susi
2024-01-17 19:05     ` Ilia Zykov
2024-01-26  1:21 ` Glenn Washburn
2024-01-26  1:35   ` Demi Marie Obenour

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=b8913e84-6ec1-4c79-9ba7-baa7783c46ef@gmail.com \
    --to=zdenek.kabelac@gmail.com \
    --cc=andy@strugglers.net \
    --cc=linux-lvm@lists.linux.dev \
    /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).