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@xxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
