Re: [linux-lvm] Fast thin volume preallocation?
>> Presumably you want a thick volume but inside a thin pool so that you >> can used snapshots? >> If so have you considered the 'external snapshot' feature? > > Yes, in some cases they are quite useful. Still, a fast volume > allocation can be an handy addition. > Hello. Can I use external snapshot for fast zero allocation? "thpool" - is lvmthin with lvm zeroing disabled # lvcreate -n ext2T -V 2TiB --thinpool thpool VG # lvchange --permission r VG/ext2T # lvcreate -n zeroed_lve -s VG/ext2T --thinpool VG/thpool Or it will be the same as zeroing enabled? Thanks. ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Fast thin volume preallocation?
Il 03-06-2019 15:23 Joe Thornber ha scritto: On Fri, May 31, 2019 at 03:13:41PM +0200, Gionatan Danti wrote: - does standard lvmthin support something similar? If not, how do you see a zero coalesce/compression/trim/whatever feature? There isn't such a feature as yet. Ok, so the NAS vendor did something custom/proprietary. This is a reason why I do *not* like such devices: how much testing and verification are done before and after such customization? Not a lot, I would say. With the next iteration of thin I'd like to get away from the fixed allocation block sizes that we're using which should greatly reduce the number of mappings that we need to create to provision a thick volume and so speed it up a lot. Interesting. Do you plan to have an dynamic chunk size bound to some minumum/maximum? If so, how do you plan to tackle situations where a single big chunk should be split due to a small CoW write happening inside the big chunk? Example: a 128MB chunk-sized thin LV which is snapshotted and a small 4K writes happening at offset 32M from chunk start. Presumably you want a thick volume but inside a thin pool so that you can used snapshots? If so have you considered the 'external snapshot' feature? Yes, in some cases they are quite useful. Still, a fast volume allocation can be an handy addition. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] A couple of questions on locking library
On Fri, May 31, 2019 at 10:47:49PM +0800, Shawn Guo wrote: > it's not possible to use an external locking extension any more, right? right > lvmlockd becomes the only clustering locking solution. right > While it supports sanlock and dlm locking library, there is no extension > support for plugging an external locking library in. right Dave ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
[linux-lvm] confused with lvm2 filter rules
Hello, I met below filter action when executed 'vgextend'. why the filter take no effect on executing pvcreate or vgcreate? ``` # ls -l /dev/disk/by-id/scsi-* lrwxrwxrwx 1 root root 9 Jun 3 20:44 /dev/disk/by-id/scsi-360073a707 -> ../../sda lrwxrwxrwx 1 root root 9 Jun 3 20:44 /dev/disk/by-id/scsi-36007c0036 -> ../../sdb lrwxrwxrwx 1 root root 9 Jun 3 20:27 /dev/disk/by-id/scsi-3600b99ec4 -> ../../sdc # pvcreate /dev/disk/by-id/scsi-36073a707 /dev/disk/by-id/scsi-36007c0036 # pvs PV VG Fmt Attr PSize PFree /dev/sda lvm2 --- 2.00g 2.00g /dev/sdb lvm2 --- 2.00g 2.00g # vgcreate vgtst /dev/disk/by-id/scsi-36073a707 /dev/disk/by-id/scsi-36007c0036hy the filter take no effect on executing pvcreate or vgcreate? # vgs VG#PV #LV #SN Attr VSize VFree vgtst 2 0 0 wz--n- 3.98g 3.98g # vgextend vgtst /dev/disk/by-id/scsi-3600b99ec4 Device /dev/disk/by-id/scsi-3600b99ec4 excluded by a filter. # vgs VG#PV #LV #SN Attr VSize VFree vgtst 2 0 0 wz--n- 3.98g 3.98g my enviroment: # rpm -qa | grep lvm2 lvm2-clvm-2.02.180-8.16.x86_64 lvm2-cmirrord-2.02.180-8.16.x86_64 lvm2-2.02.180-8.16.x86_64 the filter rules: (you can see all the disk in /dev/disk/by-id/ are rejected) # grep filter /etc/lvm/lvm.conf | grep -v "#" filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] ``` Thank you. zhm ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Fast thin volume preallocation?
On Fri, May 31, 2019 at 03:13:41PM +0200, Gionatan Danti wrote: > - does standard lvmthin support something similar? If not, how do you see a > zero coalesce/compression/trim/whatever feature? There isn't such a feature as yet. With the next iteration of thin I'd like to get away from the fixed allocation block sizes that we're using which should greatly reduce the number of mappings that we need to create to provision a thick volume and so speed it up a lot. Presumably you want a thick volume but inside a thin pool so that you can used snapshots? If so have you considered the 'external snapshot' feature? > - can I obtain something similar by simply touching (maybe with a 512B only > write) once each thin chunk? Yes. - Joe ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] A couple of questions on locking library
On Fri, May 31, 2019 at 10:38:18AM +0200, Zdenek Kabelac wrote: > Dne 31. 05. 19 v 9:13 Shawn Guo napsal(a): > >Hi David, Zdenek, > > > >Comparing to stable-2.02 branch, I noticed that there are significant > >changes around locking infrastructure on master branch. I have a > >couple of questions regarding to these changes. > > > >1. I see External Locking support was removed as part of clvmd > >removal. What's the reason for dropping External Locking support? I'm > >asking because we are investigating the possibility to use hardware > >assisted locking for cluster, in form of External Locking extension. > > > >2. It seems there have never been real support for LV (Logic Volume) > >locking. On stable-2.02 branch, the LV locking interface is used as > >activation path instead of real locking on LV. And on master branch, > >activation path gets separated off from locking infrastructure. As > >the result, the LV interface is dropped completely from locking > >infrastructure. My question is why there have never been LV locking > >support. Is the LV locking support an invalid requirement at all? Or > >it's just because no one cares about it enough to add the support? > > > >Thanks for your time, and appreciate any comment you would give here. > > With stable-2.02 branch - there was always per-LV locking. > The 'state' of the LV was matching state of lock. > > http://people.redhat.com/agk/talks/CLVM-UKUUG2007/ > > See the 'DLM – Distributed Lock Manager' That's only for lvmlockd but not clvmd, right? IIUC, LV locking semantic is used as activation for clvmd on stable-2.02. > > The lock however was always took only for top-level LV - never for those > component LVs. > > -- > > There is however believe, that users no longer use volumes with shared > activation (active at one time on multiple hosts) - so lvm2 is now being > moved > transformed to theoretically less complex locking scheme... So back to my question 1, it looks that "less complex" means it's not possible to use an external locking extension any more, right? lvmlockd becomes the only clustering locking solution. While it supports sanlock and dlm locking library, there is no extension support for plugging an external locking library in. Is my understanding above correct? I'm just trying to understand the feasibility of adding external locking library under new lvm2 locking scheme. Thanks much! Regards, Shawn ___ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
