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

[Andy Smith <andy@strugglers.net>]

Hi Phillip,

On Sat, Jan 20, 2024 at 01:00:54PM -0500, Phillip Susi wrote:
> Andy Smith <andy@strugglers.net> writes:
> > dsthost$ sudo mount /dev/mapper/slowvg-4ksectortest1 /mnt
> > mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/slowvg-4ksectortest1, missing codepage or helper program, or other error.
> >
> > So at the end here, despite msdos partition table looking correct,
> > sha256sum matching and kpartx appearing to work, dsthost can't mount
> > this filesystem. Did I miss a step or misunderstand?
> 
> Try mount -t ext4.  If that doesn't work, see what e2fsck/tune2fs say.

I've not needed that before and my instinct is that if it is needed,
something has gone wrong. But in any case it did not help:

$ sudo mount -t ext4 /dev/mapper/slowvg-4ksectortest1 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/slowvg-4ksectortest1, missing codepage or helper program, or other error.

I had posted tune2fs -l at the end of the email you're replying to;
it was from dsthost, after the move. It looks pretty normal. And as
I say, the sha256sum of the partition matches on both sides.

Here's the tuen2fs -l again:

$ sudo tune2fs -l /dev/mapper/slowvg-4ksectortest1
tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name:   4ksectortest
Last mounted on:          <not available>
Filesystem UUID:          c39bf28a-c432-4a2a-9545-5da13b8574f2
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              32512
Block count:              130048
Reserved block count:     6502
Free blocks:              120293
Free inodes:              32501
First block:              1
Block size:               1024
Fragment size:            1024
Group descriptor size:    64
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2032
Inode blocks per group:   254
Flex block group size:    16
Filesystem created:       Sat Jan 20 04:03:42 2024
Last mount time:          n/a
Last write time:          Sat Jan 20 04:03:42 2024
Mount count:              0
Maximum mount count:      -1
Last checked:             Sat Jan 20 04:03:42 2024
Check interval:           0 (<none>)
Lifetime writes:          4441 kB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      2a074d90-0ade-4dfb-b8f2-3588ffa56cf6
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0xc7322510

In a way this is all becoming academic, as it seems very
filesystem-specific. Given I generally can't poke about inside these
disk images, it looks like I will never come up with a robust
procedure for block-wise copying of these LVs.

Using hdparm to set a 512b sector may be my only way forward.

I am interested in personally knowing more though, so am happy to
try out any ideas anyone has for a while.

Thanks,
Andy