All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <phill@thesusis.net>
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 09:06:57 -0500	[thread overview]
Message-ID: <87il3scav2.fsf@vps.thesusis.net> (raw)
In-Reply-To: <ZabjW4HWOSfy8sRN@mail.bitfolk.com>

Andy Smith <andy@strugglers.net> writes:

> It's a disk image for a virtual machine that belongs to someone else
> and I don't have a say in how they choose to lay out their data
> inside of it. If they want to take what appears to them to be a
> plain block device and put a partition table on it, or write their
> own invented fs directly on it, in this case I have no latitude to
> prohibit that.

If it's a VM then IIRC, it should still be presented to the VM as if it
were using 512 byte sectors, no matter what size the storage in the host
system uses.  Did you try just booting the VM or did you decide to use
kpartx to verify the image from the host first?

> Since I don't generally know what is on the disk image as mentioned,
> I can't really do this. Empty space isn't too much of an issue since
> I generally actually use something that does a block-based sync
> without copying matching chunks, so an empty source chunk will match
> with an empty destination chunk and be skipped. But I re-did it with
> plain dd just to be sure it wasn't a tooling issue.

It sounds like you are assuming that the empty space contains all zeros
and so will be de-duplicated with other space that contains all zeros.
Instead it often tends to contain old data that isn't going to match
something else, and so will be sent, even though it isn't needed.

  parent reply	other threads:[~2024-01-17 14:07 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 [this message]
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
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=87il3scav2.fsf@vps.thesusis.net \
    --to=phill@thesusis.net \
    --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 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.