On Mon, Jan 15, 2024 at 1:49 AM 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. 512e vs 4096 should not matter at all for LVM. LVM and Linux at their core work at page-size and that is 4k. You should probably include an fdisk -l <lv> from the working system and a show what device it is mounted from. And a fdisk -l <device-it-was-dd-ed-to> Note PV == physical device (a disk sometimes partitioned). VG = Volume Group (a group of PVs) LV = logical volume (section and/or entire PV's mapped together, rarely partitioned). If you dd'ed the entire LV over to another disk, did you put it on the entire disk or inside a partition on a disk? And if you put the partition on the LV after the ext4 fs then the partition may have damaged the ext4 fs. If inside a partition on a disk, then partitions on partitions get tricky as I have found you often need to force a read/create of the partition entries inside that device. If you find the right command and run it against the partitioned device (that has its own partition) then you may be able to mount it (kpartx -a /dev/sdx1, assuming sdx1 is where you copied the LV). Note this will not survive reboot, and you will need to run it again). The device after partition of a partition is created would be something like /dev/sdx1p1. If that is the case you may also have better luck copying just the specific partition inside the LV over that has the filesystem and not messing with the partition. And if you changed the start point of the partition were the ext4 fs is then there will be no ext4 fs were it is expected and nothing will find it. Note the partition on the LV means that the ext4 fs does not start where any tools expect it to start and so nothing can find it, and as such you need to get the partition mapping defined.
