All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stuart D. Gathman" <stuart@gathman.org>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Ingo Franzki <ifranzki@linux.ibm.com>
Subject: Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size
Date: Wed, 27 Feb 2019 20:52:04 -0500 (EST)	[thread overview]
Message-ID: <alpine.LRH.2.21.1902272034560.17954@fairfax.gathman.org> (raw)
In-Reply-To: <be7e5609-7377-d380-1197-7c75ab5999d4@gmail.com>

On Thu, 28 Feb 2019, Cesare Leonardi wrote:

> Not to be pedantic, but what do you mean with physical block? Because with 
> modern disks the term is not always clear. Let's take a mechanical disk with 
> 512e sectors, that is with 4k sectors but exposed as 512 byte sectors. Fdisk 
> will refer to it with these terms:
> Sector size (logical/physical): 512 bytes / 4096 bytes
>
> What you are referring as physical size is actually the logical size reported 
> by fdisk, right? And if it's correct, I guess that should be safe to add the 
> above disk with 512e sectors to an LVM storage composed only by disks with 
> real 512 byte sectors. I expect that from the LVM point of view this should 
> not be even considered a mixed sector size setup, even if the real physical 
> sector size of the added disk is 4096 byte.
>
> Do you agree or do you think it would be better to test this specific setup?

I would definitely test it, using the same test script that reproduces the 
problem with loopback devices.

That said, I believe you are right - it should definitely work.  Most of
my drives are 512/4096 logical/phys.  If you actually write a single 512
byte sector, however, the disk firmware will have to do a
read/modify/write cycle - which can tank performance.

hdparm will report logical and physical sector size - but there doesn't
seem to be an option to set logical sectory size.  There really is no
need once you already support a smaller logical sector size, as the
performance hit can be avoided by aligned filesystems with 4k+ block
size (most modern filesystems).

Once I encountered a bug in drive firmware where the R/M/W did not
work correctly with certain read/write patterns (involving unaligned
multi sector writes).  I do not wish that on anyone.  (don't worry,
that drive model is long gone...).

-- 
 	      Stuart D. Gathman <stuart@gathman.org>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

  reply	other threads:[~2019-02-28  1:52 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-25 15:33 [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size Ingo Franzki
2019-02-27  0:00 ` Cesare Leonardi
2019-02-27  8:49   ` Ingo Franzki
2019-02-27 14:59     ` Stuart D. Gathman
2019-02-27 17:05       ` Ingo Franzki
2019-03-02  1:37         ` L A Walsh
2019-02-28  1:31     ` Cesare Leonardi
2019-02-28  1:52       ` Stuart D. Gathman [this message]
2019-02-28  8:41       ` Ingo Franzki
2019-02-28  9:48         ` Ilia Zykov
2019-02-28 10:10           ` Ingo Franzki
2019-02-28 10:41             ` Ilia Zykov
2019-02-28 10:50             ` Ilia Zykov
2019-02-28 13:13               ` Ilia Zykov
2019-03-01  1:24         ` Cesare Leonardi
2019-03-01  2:56           ` [linux-lvm] Filesystem corruption with LVM's pvmove onto a PVwith " Bernd Eckenfels
2019-03-01  8:00             ` Ingo Franzki
2019-03-01  3:41           ` [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with " Stuart D. Gathman
2019-03-01  7:59             ` Ingo Franzki
2019-03-01  8:05           ` Ingo Franzki
2019-03-02  1:36             ` Cesare Leonardi
2019-03-02 20:25               ` Nir Soffer
2019-03-04 22:45                 ` Cesare Leonardi
2019-03-04 23:22                   ` Nir Soffer
2019-03-05  7:54                     ` Ingo Franzki
2019-03-04  9:12               ` Ingo Franzki
2019-03-04 22:10                 ` Cesare Leonardi
2019-03-05  0:12                   ` Stuart D. Gathman
2019-03-05  7:53                     ` Ingo Franzki
2019-03-05  9:29                       ` Ilia Zykov
2019-03-05 11:42                         ` Ingo Franzki
2019-03-05 16:29                         ` Nir Soffer
2019-03-05 16:36                           ` David Teigland
2019-03-05 16:56                             ` Stuart D. Gathman
2019-02-28 14:36 ` Ilia Zykov
2019-02-28 16:30   ` Ingo Franzki
2019-02-28 18:11     ` Ilia Zykov

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=alpine.LRH.2.21.1902272034560.17954@fairfax.gathman.org \
    --to=stuart@gathman.org \
    --cc=ifranzki@linux.ibm.com \
    --cc=linux-lvm@redhat.com \
    /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.