All of lore.kernel.org
 help / color / mirror / Atom feed
From: Itai Handler <itai.handler@gmail.com>
To: David Teigland <teigland@redhat.com>
Cc: Zdenek Kabelac <zkabelac@redhat.com>, lvm-devel@lists.linux.dev
Subject: Re: [PATCH] label: fix writes when the logical block size is not 512 or 4096
Date: Sun,  1 Nov 2026 14:19:43 +0200	[thread overview]
Message-ID: <20261101121943.1867919-1-itai.handler@gmail.com> (raw)
In-Reply-To: <auOUULF672SkVzt8@redhat.com>

Hi David,

On Thu, Oct 29, 2026 at 01:45:36PM -0500, David Teigland wrote:
> This last line touches on the main concern I have with the rouding up.
> dev_set_last_byte was added by aecf542126640faa17c240afbb1ea61f11355c39
> which addressed a very subtle data corruption bug that was introduced
> by the bcache (now blkio) layer.  In order to safely round up, we need
> to be certain that no VGs exist in which that rounded up space could
> be used by LV extents.  In the past (less so today), the pe_start value
> could be highly variable due to several config settings or command
> line options.  We'll need to prove that current and past versions of
> lvm would not have placed pe_start within the rounded-up space.

Right, my last line only covered the default pe_start.  But I think
the kernel makes rounding up safe for any pe_start, whatever version
or option chose it, as long as lvm rounds up to the logical block
size and no further.

Rounding adds the bytes from the end of the area being written
(label, mda header or metadata area) up to the next multiple of the
logical block size.  An extent can't overlap these areas, so if it
holds any of the added bytes, it starts among them, between two
multiples of the logical block size.  device-mapper refuses to map
such an extent (device_area_is_invalid() in dm-table.c, since
2.6.31), so no active LV can write those bytes, and writing back what
lvm read there changes nothing.

For example, with this patch, on a loop device with 2048-byte blocks:

  # pvcreate --dataalignmentoffset 1k /dev/loop0
  # vgcreate vg /dev/loop0
  # lvcreate -l1 -n lv vg
    device-mapper: reload ioctl on  (252:0) failed: Invalid argument
    Failed to activate new LV vg/lv.

and the kernel logs "start=2050 not aligned to h/w logical block size
2048 of loop0".  pe_start is 1049600 bytes (sector 2050), so metadata
writes that end there are rounded up 1KiB into the first extent, but
no LV can use that extent.

However, main doesn't always stop at the logical block size: with 1K
or 2K logical and 4K physical blocks, such as dm-crypt with 2048-byte
sectors on a 512e disk, it rounds up to 4096.  If pe_start is a
multiple of the logical block size but not of 4096, the first extent
can be active, and a metadata update puts up to 3KiB of old data back
at its start.  I reproduced this lost write with scsi_debug on main,
and with Ubuntu's 2.03.11 and Debian's 2.03.31.  It needs an unusual
pe_start, so I doubt anyone has hit it.

So I'm sending a fix for that first, as a separate patch on top of
main: "label: don't round writes past the logical block size".  Then
I'll send v2 of this patch on top of it, with the rounding moved into
blkio as Zdenek suggested, using the logical block size of each fd
(BLKSSZGET).  Compared with main plus that fix, v2 would only change
devices where lvm can't write today.

Thanks,
Itai

      reply	other threads:[~2026-11-01 12:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 12:53 [PATCH] label: fix writes when the logical block size is not 512 or 4096 Itai Handler
2026-10-29 13:12 ` Zdenek Kabelac
2026-10-29 13:53   ` Itai Handler
2026-10-29 18:45     ` David Teigland
2026-11-01 12:19       ` Itai Handler [this message]

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=20261101121943.1867919-1-itai.handler@gmail.com \
    --to=itai.handler@gmail.com \
    --cc=lvm-devel@lists.linux.dev \
    --cc=teigland@redhat.com \
    --cc=zkabelac@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.