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

[Andy Smith <andy@strugglers.net>]

Hi,

On Tue, Jan 16, 2024 at 01:24:29PM -0500, Phillip Susi wrote:
> Andy Smith <andy@strugglers.net> writes:
> 
> > 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.
> 
> You mean you put a partition table inside of the logical volume?  Why?

It's a disk image for a virtual machine that belongs to someone else
and I don't have a say in how they choose to lay out their data
inside of it. If they want to take what appears to them to be a
plain block device and put a partition table on it, or write their
own invented fs directly on it, in this case I have no latitude to
prohibit that.

It hasn't been an issue before.

> > I have confirmed with sha256sum that the content of the
> > image/partition remains the same on source and destination.
> 
> If you have already modified the partition table, then how could it
> still have the same sha256sum?

I did a sha256sum of the image before I tampered with it and it
matched.

I then recreated the partition table, which allowed me to use
"kpartx" to expose the first partition as a loop device. A sha256sum
of this first partition matches a sha256sum of the first partition
on the source disk image.

> > 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.
> 
> LVM doesn't really know or care about it.

I agree, but I was wondering if it would allow me some way around
the issue, and it's what I have as "my" top layer anyway.

> No, it wouldn't be a problem without the partition table.  ext4 uses its
> own block size, which is pretty much always 4k.  It doesn't know or care
> about the underlying disk logical sector size.

I've found quite a few people having similar problems to me so I'm
not sure about this, but I haven't had chance to test it yet. I
will try it out before I explore hdparm.

> For that matter, using dd wastes a lot of time and bandwidth copying all
> of the unused space in the filesystem.  I'd suggest using e2image
> instead.  It's smart enough to skip the unused space.

Since I don't generally know what is on the disk image as mentioned,
I can't really do this. Empty space isn't too much of an issue since
I generally actually use something that does a block-based sync
without copying matching chunks, so an empty source chunk will match
with an empty destination chunk and be skipped. But I re-did it with
plain dd just to be sure it wasn't a tooling issue.

This is getting a bit off track though, as the issue appears to be
the 512e vs 4Kn nature of the underlying drives, which I can't
sidestep by using fs-level tools.

Thanks,
Andy