From: Cesare Leonardi <celeonar@gmail.com>
To: Ingo Franzki <ifranzki@linux.ibm.com>,
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: Fri, 1 Mar 2019 02:24:24 +0100 [thread overview]
Message-ID: <d60d4e1c-ad67-8f3f-b159-13cb3923447f@gmail.com> (raw)
In-Reply-To: <11dcbee0-ec65-d5d2-b07c-9937b99cc5b4@linux.ibm.com>
On 28/02/19 09:41, Ingo Franzki wrote:
> Well, there are the following 2 commands:
>
> Get physical block size:
> blockdev --getpbsz <device>
> Get logical block size:
> blockdev --getbsz <device>
I didn't know the blockdev command and, to recap, we have:
--getpbsz: physical sector size
--getss: logical sector size
--getbsz: blocksize used internally by the kernel
getpbsz/getss correspond to physical/logical sector size reported by
fdisk, smartctl, etc.
> 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...
I've done the test suggested by Stuart and it seems to contradict this.
I have pvmoved data from a 512/512 (logical/physical) disk to a newly
added 512/4096 disk but I had no data corruption. Unfortunately I
haven't any native 4k disk to repeat the same test.
Here is what I've done.
/dev/sdb: SSD with 512/512 sector size
/dev/sdc: mechanical disk with 512/4096 sector size
# blockdev -v --getss --getpbsz --getbsz /dev/sdb
get logical block (sector) size: 512
get physical block (sector) size: 512
get blocksize: 4096
# blockdev -v --getss --getpbsz --getbsz /dev/sdc
get logical block (sector) size: 512
get physical block (sector) size: 4096
get blocksize: 4096
# pvcreate /dev/sdb4
# vgcreate vgtest /dev/sdb4
# lvcreate -L 1G vgtest /dev/sdb4
# mkfs.ext4 /dev/mapper/vgtest-lvol0
# mkdir /media/test
# mount /dev/mapper/vgtest-lvol0 /media/test
# cp -a SOMEDATA /media/test/
# umount /media/test
# fsck.ext4 -f /dev/mapper/vgtest-lvol0
Filesystem created and no error on it. Now the disk with different
physical size:
# pvcreate /dev/sdc1
# vgextend vgtest /dev/sdc1
# pvmove /dev/sdb4 /dev/sdc1
# fsck.ext4 -f /dev/mapper/vgtest-lvol0
# mount /dev/mapper/vgtest-lvol0 /media/test
# ls /media/test/
The fsck command reports no errors, the filesystem is mountable and the
data is there.
Looks like physical sector size didn't matter here. Or I'm missing
something?
Cesare.
next prev parent reply other threads:[~2019-03-01 1:24 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
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 [this message]
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=d60d4e1c-ad67-8f3f-b159-13cb3923447f@gmail.com \
--to=celeonar@gmail.com \
--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.