From: Andy Smith <andy@strugglers.net>
To: linux-lvm@lists.linux.dev
Subject: Any way in LVM to deal with 512e vs 4Kn physical devices?
Date: Mon, 15 Jan 2024 07:30:51 +0000 [thread overview]
Message-ID: <ZaTfK/aagY+A8C3N@mail.bitfolk.com> (raw)
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.
Thanks,
Andy
next reply other threads:[~2024-01-15 7:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 7:30 Andy Smith [this message]
2024-01-15 21:07 ` Any way in LVM to deal with 512e vs 4Kn physical devices? Roger Heflin
2024-01-16 18:24 ` Phillip Susi
2024-01-16 20:13 ` Andy Smith
2024-01-17 7:22 ` Andy Smith
2024-01-17 12:13 ` Roger Heflin
2024-01-17 14:10 ` Phillip Susi
2024-01-20 4:45 ` Andy Smith
2024-01-20 18:00 ` Phillip Susi
2024-01-20 20:56 ` Andy Smith
2024-01-24 16:18 ` Phillip Susi
2024-01-24 21:17 ` Roger Heflin
2024-01-25 19:05 ` Phillip Susi
2024-01-17 14:06 ` Phillip Susi
2024-01-16 19:30 ` Ilia Zykov
2024-01-16 20:17 ` Andy Smith
2024-01-17 10:36 ` Zdenek Kabelac
2024-01-17 11:21 ` Andy Smith
2024-01-17 11:48 ` Zdenek Kabelac
2024-01-17 14:24 ` Phillip Susi
2024-01-17 19:05 ` Ilia Zykov
2024-01-26 1:21 ` Glenn Washburn
2024-01-26 1:35 ` Demi Marie Obenour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZaTfK/aagY+A8C3N@mail.bitfolk.com \
--to=andy@strugglers.net \
--cc=linux-lvm@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).