All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <phill@thesusis.net>
To: Ilia Zykov <mail@service4.ru>, Andy Smith <andy@strugglers.net>,
	linux-lvm@lists.linux.dev
Subject: Re: Any way in LVM to deal with 512e vs 4Kn physical devices?
Date: Wed, 17 Jan 2024 09:24:10 -0500	[thread overview]
Message-ID: <87cyu0ca2d.fsf@vps.thesusis.net> (raw)
In-Reply-To: <451707ab-ec8e-8f19-6813-445a184fda3a@service4.ru>

Ilia Zykov <mail@service4.ru> writes:

> Hello.
>
> Sorry, I could be wrong, but I was encountered this problem a long time ago.
> You cannot transfer ext4 from a device with a phys sector 512 bite to a 
> device with phys 4k sector device.
> As far as I remember, ext4 uses this size to perform atomic operations.
> Because on the new disk it is not possible to perform an atomic 
> operation with data of 512 bytes,
> then it is impossible to transfer such a FS.
> See ENVIROMENTS for mkfs.ext4: "MKE2FS_DEVICE_SECTSIZE", 
> "MKE2FS_DEVICE_PHYS_SECTSIZE".

Ext[234] does IO in units of blocks.  In the days of 80 MB hard disks,
it could use a block size of 1 or 2 KB.  These days it pretty much
always uses 4 KB.  I'm almost certain that those environment variables
are to override what the kernel detects for testing purposes, and the
only thing mkfs does with this information is to force a 4K block size (
when that is the sector size ), even if the fs is small enough that it
otherwise would use 1 or 2.


  parent reply	other threads:[~2024-01-17 14:24 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
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 [this message]
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=87cyu0ca2d.fsf@vps.thesusis.net \
    --to=phill@thesusis.net \
    --cc=andy@strugglers.net \
    --cc=linux-lvm@lists.linux.dev \
    --cc=mail@service4.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.