Re: Any way in LVM to deal with 512e vs 4Kn physical devices?

[Demi Marie Obenour <demi@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 3137 bytes --]

On Thu, Jan 25, 2024 at 07:21:55PM -0600, Glenn Washburn wrote:
> On Mon, 15 Jan 2024 07:30:51 +0000
> Andy Smith <andy@strugglers.net> wrote:
> 
> > Hi,
> > 
> > On machine 'A' I have a pair of:
> > 
> > Device Model:     Samsung SSD 870 EVO 4TB
> > Sector Size:      512 bytes logical/physical
> > 
> > on top of this is an mdadm RAID-1 and that is an LVM PV.
> > 
> > One of the LVs has been partitioned with an MBR and a single
> > partition spanning the whole of the 400GiB LV.
> > 
> > I took a dd of this LV and transferred it to an identically-sized
> > LV on machine 'B' which has a pair of:
> > 
> > Device Model:     HGST HUS726T6TALN6L4
> > Sector Size:      4096 bytes logical/physical
> > 
> > The LV there when examined in a partitioning tool such as "fdisk"
> > now thinks it has a 3.2TiB partition and it is not usable.
> > Correcting the partition sector numbers allows for use of, for
> > example, "kpartx", to expose the partition as a loop device but the
> > ext4 driver and fsck.ext4 remain unable to detect a superblock.
> > 
> > I have confirmed with sha256sum that the content of the
> > image/partition remains the same on source and destination.
> > 
> > So, clearly the issue is the 512e sector size on source vs 4Kn on
> > destination. Is there any way to work around this in LVM? My issue
> > is that I would like to be able to move images of disks/filesystems
> > around at the block level without mounting/creating filesystem and
> > transferring with an fs-level application.
> > 
> > If not, then possibly I can use hdparm to set the 4Kn drives to 512,
> > which will obviously involve destroying their contents, but that is
> > fine at this stage.
> > 
> > I don't think the presence of a partition (as opposed to an ext4
> > filesystem directly upon the LV) is relevant; I think the same
> > issues would occur with a direct filesystem. I mention it only for
> > completeness. Also, I realise that the problems would also happen
> > without LVM. I just wonder if there is any workaround at the LVM
> > layer, since that is already used here.
> 
> I've had this issue before and there is a very simple solution. It does
> not work at the LVM layer though, but I suspect what you really care
> about is having it work at the software, as opposed to hardware or
> firmware layer.
> 
> Since the software that created the image did so assuming a 512b sector
> size, create a block device that has that sector size. The trick is to
> use loopdev to create a layer that does the translation from 512b to 4k
> sector size. See the "--sector-size" argument to losetup.

The atomicity guarantees of devices with different sector sizes are
different, so this is lying to the guest and could cause data corruption
in the event of a power failure.  The only “clean” way to do this is
with something that supports atomic writes with a granularity that is
different than what the hardware does.  ZFS zvols might be able to do
that, since they are copy-on-write internally.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]