Hi, On Tue, Jan 16, 2024 at 01:24:29PM -0500, Phillip Susi wrote: > Andy Smith <andy@xxxxxxxxxxxxxx> 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
