Re: [linux-lvm] lvmcache with vdo - inconsistent block size

2020-09-17 Thread Zdenek Kabelac
Dne 17. 09. 20 v 23:41 Gionatan Danti napsal(a): Il 2020-09-17 21:27 Zdenek Kabelac ha scritto: You've most likely found the bug and this should be likely disable (and enabled only with some force option). Hi Zdenek, I am not sure about what bug I found - can you be more explicit? Problem

Re: [linux-lvm] lvmcache with vdo - inconsistent block size

2020-09-17 Thread Gionatan Danti
Il 2020-09-17 21:27 Zdenek Kabelac ha scritto: You've most likely found the bug and this should be likely disable (and enabled only with some force option). Hi Zdenek, I am not sure about what bug I found - can you be more explicit? Problem is, when such device stack is used for XFS -

Re: [linux-lvm] lvm limitations

2020-09-17 Thread Zdenek Kabelac
Dne 16. 09. 20 v 0:26 Gionatan Danti napsal(a): Il 2020-09-15 23:47 Zdenek Kabelac ha scritto: Speaking of thin volumes - there can be at most 2^24 thin devices (this is hard limit you've ask for ;)) - but you have only  ~16GiB of metadata to store all of them - which gives you ~1KiB of data

Re: [linux-lvm] lvmcache with vdo - inconsistent block size

2020-09-17 Thread Zdenek Kabelac
Dne 16. 09. 20 v 0:32 Gionatan Danti napsal(a): Il 2020-09-15 20:34 Zdenek Kabelac ha scritto: Dne 14. 09. 20 v 23:44 Gionatan Danti napsal(a): Hi all, I am testing lvmcache with VDO and I have issue with devices block size. The big & slow VDO device is on top of a 4-disk MD RAID 10 device

Re: [linux-lvm] lvm limitations

2020-09-17 Thread Zdenek Kabelac
Dne 16. 09. 20 v 6:25 Tomas Dalebjörk napsal(a): thanks for all the good reflections the intention is to see if backups can be done in a much more easy way than have ever been built before Assuming you have checked projects like 'snapper' ? another solution could be to store the lv as file

Re: [linux-lvm] lvm limitations

2020-09-17 Thread Zdenek Kabelac
Dne 16. 09. 20 v 6:58 Tomas Dalebjörk napsal(a): just curious about this: Worth to note there is fixed strict limit of the ~16GiB maximum thin-pool kernel metadata size - which surely can be exhausted - mapping holds info about bTree mappings and sharing chunks between devices would that

Re: [linux-lvm] Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180

2020-09-17 Thread Roger Heflin
There is only a reject, there are no included devices. Once you add a filter it overrides the default filter including all I believe. The fixes may have been fixing filtering as once you specify a filter then there is no implied include (anymore). You should probably look at the list of fixes

Re: [linux-lvm] [PATCH v2] lvs: add -o lv_usable

2020-09-17 Thread Heinz Mauelshagen
On 9/10/20 8:34 AM, heming.zhao wrote: On 9/10/20 1:17 AM, Zdenek Kabelac wrote: Dne 09. 09. 20 v 18:47 Zhao Heming napsal(a): report LV is usable for upper layer. leave issues - this patch doesn't contain dm table comparison. So if the disk    is removed then re-inserted, but the re-inserted

Re: [linux-lvm] Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180

2020-09-17 Thread KrishnaMurali Chennuboina
Hi Roger, Thanks for the information shared. Filter which we used in our conf file was, # Accept every block device: filter = [ "r|^/dev/drbd.*|" ] Thanks. On Tue, 15 Sep 2020 at 16:36, Roger Heflin wrote: > #1: > Device /dev/sda3 excluded by a filter.) > Failed to execute

Re: [linux-lvm] Issue after upgrading the LVM2 package from 2.02.176 to 2.02.180

2020-09-17 Thread KrishnaMurali Chennuboina
Hi Roger, Missed to add my comment in the earlier mail. >From the filter it should not exclude /dev/sda*. But not sure why it is being excluded while executing pvcreate command. Thanks. On Tue, 15 Sep 2020 at 18:28, KrishnaMurali Chennuboina < krishchennu...@gmail.com> wrote: > Hi Roger, > >