Re: exposing snapshot block device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Il 23-10-2019 17:37 Zdenek Kabelac ha scritto:
Hi

If you use 1MiB chunksize for thin-pool and you use 'dd' with proper bs size
and you write 'aligned' on 1MiB boundary (be sure you user  directIO,
so you are not a victim of some page cache flushing...) - there should
not be any useless read.

If you still do see such read - and you can easily reproduce this with
latest kernel - report a bug please with your reproducer and results.

Regards

Zdenek

OK, I triple-checked my numbers and you are right: on a fully updated CentOS 7.7 x86-64 box with kernel-3.10.0-1062.4.1 and lvm2-2.02.185-2, it seems that the behavior I observed on older (>2 years ago) is not present anymore.

Take this original lvm setup:
[root@localhost ~]# lvs -o +chunk_size
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Chunk root centos -wi-ao---- <6.20g 0 swap centos -wi-ao---- 512.00m 0 thinpool centos twi-aot--- 1.00g 25.00 14.16 64.00k thinvol centos Vwi-a-t--- 256.00m thinpool 100.00 0

Taking a snapshot (lvcreate -s /dev/centos/thinvol -n thinsnap) and overwriting 1 MB of data on origin via "dd if=/dev/urandom of=/dev/centos/thinvol bs=1M count=32 oflag=direct" results in the following I/O to/from disk:

[root@localhost ~]# dstat -d -D sdc
---dsk/sdc---
 read  writ
1036k   32M

As you can see, while 1 MB was indeed read (due to metadata read?), no other read amplification occoured.

Now I got curious to see if zeroing behave in the same manner. So, I deleted thinsnap & thinvol, toggled zeroing on (lvchange -Zy centos/thinpool), and recreated thinvol:

[root@localhost ~]# lvs -o +chunk_size
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Chunk root centos -wi-ao---- <6.20g 0 swap centos -wi-ao---- 512.00m 0 thinpool centos twi-aotz-- 1.00g 0.00 11.04 64.00k thinvol centos Vwi-a-tz-- 256.00m thinpool 0.00 0

[root@localhost ~]# dstat -d -D sdc
--dsk/sdc--
 read  writ
   0    13M
 520k   19M

Again, no write amplificaton occoured.

Kudos to all the team for optimizing lvmthin in this manner, it really is a flexible and great performing tool.
Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8

_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/





[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux