All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Franzki <ifranzki@linux.ibm.com>
To: Ilia Zykov <mail@izyk.ru>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size
Date: Thu, 28 Feb 2019 11:10:27 +0100	[thread overview]
Message-ID: <3f94a1df-d333-70fe-56ab-3661b384e028@linux.ibm.com> (raw)
In-Reply-To: <b54c26c3-ce43-674e-d620-28fc2f369956@izyk.ru>

On 28.02.2019 10:48, Ilia Zykov wrote:
>>
>> Well, there are the following 2 commands:
>>
>> Get physical block size: 
>>  blockdev --getpbsz <device>
>> Get logical block size:
>>  blockdev --getbsz <device>
>>
>> Filesystems seem to care about the physical block size only, not the logical block size.
>>
>> So as soon as you have PVs with different physical block sizes (as reported by blockdev --getpbsz) I would be very careful...
> 
> Hello everybody.
> Maybe, I don’t understand what do you mean. What the logical block size
> mean? But on my machines(CentOS7), this utility get me the strange
> results (output reduced):
> 
>  smartctl -i /dev/sda; blockdev --getbsz --getpbsz /dev/sda
> Device Model:     INTEL SSDSC2KB480G8
> User Capacity:    480,103,981,056 bytes [480 GB]
> Sector Sizes:     512 bytes logical, 4096 bytes physical
> Rotation Rate:    Solid State Device
> 4096
> 4096
> 
>  smartctl -i /dev/sdb; blockdev --getbsz --getpbsz /dev/sdb
> Device Model:     HGST HUS722T2TALA604
> User Capacity:    2,000,398,934,016 bytes [2.00 TB]
> Sector Size:      512 bytes logical/physical
> Rotation Rate:    7200 rpm
> Form Factor:      3.5 inches
> 4096
> 512
> 
> As you see “–getbsz” forever 4096.
I also see logical block size to be 4096 for all devices on my system.
> But I think it must be forever 512.
> What does it mean?
I have seen the following description about logical and physical block sizes somewhere in the internet:
"Logical block sizes are the units used by the 'kernel' for read/write operations.
Physical block sizes are the units which 'disk controllers' use for read/write operations."

For the problem mentioned in this thread, the physical block size is what you are looking for.
> 
> Thank you.
> Ilia.
> 


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Fax: ++49 (0)7031-16-3456
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

  reply	other threads:[~2019-02-28 10:10 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
2019-02-28  8:41       ` Ingo Franzki
2019-02-28  9:48         ` Ilia Zykov
2019-02-28 10:10           ` Ingo Franzki [this message]
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=3f94a1df-d333-70fe-56ab-3661b384e028@linux.ibm.com \
    --to=ifranzki@linux.ibm.com \
    --cc=linux-lvm@redhat.com \
    --cc=mail@izyk.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.