From: Phillip Susi <phill@thesusis.net>
To: Andy Smith <andy@strugglers.net>
Cc: linux-lvm@lists.linux.dev
Subject: Re: Any way in LVM to deal with 512e vs 4Kn physical devices?
Date: Wed, 24 Jan 2024 11:18:36 -0500 [thread overview]
Message-ID: <8734umiu1v.fsf@vps.thesusis.net> (raw)
In-Reply-To: <ZawzYqFyvDu8PgZ3@mail.bitfolk.com>
Andy Smith <andy@strugglers.net> writes:
>> 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:
If the fs is listed in /etc/fstab, then mount finds the fs type from
there. Otherwise, you have to specify it. At least, that used to be
the case. This may have changed at some point and I still do it from
mussle memory.
> Here's the tuen2fs -l again:
If tune2fs recognizes it then it should be fine. e2fsck -f should be
the final arbiter of whether there is anything wrong with the filesystem
though. You might check dmesg as mount suggests for any errors from the
kernel explainging why it can't mount the filesystem.
> 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.
It is filesystem specific. I believe FAT won't work right from this
transition because it does embed the sector size in its boot sector.
Due to its backward compatability, NTFS does this as well, though fixing
this to reflect the new size isn't hard. Possibly HFS and iso9660 as
well, but most common linux filesystems, such as ext4 and btrfs, already
use 4k block sizes and so don't care about the sector size.
next prev parent reply other threads:[~2024-01-24 16:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 7:30 Any way in LVM to deal with 512e vs 4Kn physical devices? Andy Smith
2024-01-15 21:07 ` 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 [this message]
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=8734umiu1v.fsf@vps.thesusis.net \
--to=phill@thesusis.net \
--cc=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 NNTP newsgroup(s).