Re: [linux-lvm] LVM thin provisioning on encrypted root unreliable

2019-02-28 Thread Chris Murphy
On Thu, Feb 28, 2019 at 2:32 PM kurcze wrote: > > Hello everyone, > > > I can't manage to get thinly provisioned LVM setup to work. > > The problem is: I can't get to the decryption prompt to enter a password > to decrypt root filesystem. It just hangs there. > > My Setup: > > VG with 3 PVs: 1

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Stuart D. Gathman
On Fri, 1 Mar 2019, Cesare Leonardi wrote: 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

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Cesare Leonardi
On 28/02/19 09:41, Ingo Franzki wrote: Well, there are the following 2 commands: Get physical block size: blockdev --getpbsz Get logical block size: blockdev --getbsz I didn't know the blockdev command and, to recap, we have: --getpbsz: physical sector size --getss: logical sector size

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Ilia Zykov
> At the time the file system was created (possibly may years ago), I did not > know that I would ever move it to a device with a larger block size. > For this purpose all 4k disks have logical sector size 512. Don't look at "blockdev --getbsz" it's not property of physical(real) device.

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Ingo Franzki
On 28.02.2019 15:36, Ilia Zykov wrote: >> Discarding device blocks: done >> Creating filesystem with 307200 1k blocks and 76912 inodes >> .. >> # pvs >> /dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument >> /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Ilia Zykov
> Discarding device blocks: done > Creating filesystem with 307200 1k blocks and 76912 inodes > .. > # pvs > /dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument > /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid argument > /dev/LOOP_VG/LV: read failed

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Ilia Zykov
>> >> 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

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Ingo Franzki
On 28.02.2019 10:48, Ilia Zykov wrote: >> >> Well, there are the following 2 commands: >> >> Get physical block size: >> blockdev --getpbsz >> Get logical block size: >> blockdev --getbsz >> >> Filesystems seem to care about the physical block size only, not the logical >> block size. >> >>

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Ilia Zykov
> > Well, there are the following 2 commands: > > Get physical block size: > blockdev --getpbsz > Get logical block size: > blockdev --getbsz > > Filesystems seem to care about the physical block size only, not the logical > block size. > > So as soon as you have PVs with different

Re: [linux-lvm] Filesystem corruption with LVM's pvmove onto a PV with a larger physical block size

2019-02-28 Thread Ingo Franzki
On 28.02.2019 02:31, Cesare Leonardi wrote: > On 27/02/19 09:49, Ingo Franzki wrote: >> As far as I can tell: Yes if you pvmove data around or lvextend an LV onto >> another PV with a larger physical block size that is dangerous. >> Creating new LVs and thus new file systems on mixed