* [linux-lvm] Mirror allocation policy
@ 2021-01-05 19:31 Phillip Susi
2021-01-05 20:47 ` Alasdair G Kergon
0 siblings, 1 reply; 6+ messages in thread
From: Phillip Susi @ 2021-01-05 19:31 UTC (permalink / raw)
To: linux-lvm
I seem to remember ( and found some references on the web ) that there
used to be a way to change the allocation policy when creating a mirror
from the default of strict ( must use different pvs ), but I can't find
a mention of strict in the man pages these days. I did see the option
for --alloc anywhere but lvconvert still refuses to change an lv into a
mirror saying that it can't find the extents ( there are plenty of
extents, but only one pv ).
How can I forge it to make the mirror on a single pv? Alternatively,
how can I create a copy of an lv ( I was planning to mirror, then
--splitmirror ).
_______________________________________________
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Mirror allocation policy
2021-01-05 19:31 [linux-lvm] Mirror allocation policy Phillip Susi
@ 2021-01-05 20:47 ` Alasdair G Kergon
2021-01-05 21:10 ` Phillip Susi
0 siblings, 1 reply; 6+ messages in thread
From: Alasdair G Kergon @ 2021-01-05 20:47 UTC (permalink / raw)
To: LVM general discussion and development
On Tue, Jan 05, 2021 at 02:31:00PM -0500, Phillip Susi wrote:
> How can I forge it to make the mirror on a single pv?
If --alloc anywhere isn't doing the trick, you'll need to dig into
the -vvvv output to try to understand why. There might be
a config option setting getting in the way disabling the choice you want
it to make, or if it's an algorithmic issue you might try to coax it to
do the right thing by removing whatever choice it has in the allocation
by specifying the actual pv:extent ranges it must use on the command line.
Alasdair
_______________________________________________
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Mirror allocation policy
2021-01-05 20:47 ` Alasdair G Kergon
@ 2021-01-05 21:10 ` Phillip Susi
2021-01-06 1:52 ` Alasdair G Kergon
0 siblings, 1 reply; 6+ messages in thread
From: Phillip Susi @ 2021-01-05 21:10 UTC (permalink / raw)
To: LVM general discussion and development; +Cc: Alasdair G Kergon
Alasdair G Kergon writes:
> On Tue, Jan 05, 2021 at 02:31:00PM -0500, Phillip Susi wrote:
>> How can I forge it to make the mirror on a single pv?
>
> If --alloc anywhere isn't doing the trick, you'll need to dig into
> the -vvvv output to try to understand why. There might be
> a config option setting getting in the way disabling the choice you want
> it to make, or if it's an algorithmic issue you might try to coax it to
I'm not seeing a whole lot here other than what appears to be this flat
out refusal to use extents from the same pv:
#metadata/lv_manip.c:2535 Not using free space on existing
parallel PV /dev/md1.
Limiting the allocation to two specific extent ranges does not help either.
Full log:
#libdm-config.c:1061 Setting
allocation/mirror_logs_require_separate_pvs to 0
#metadata/lv_manip.c:3439 Adjusted allocation request to 7681
logical extents. Existing size 0. New size 7681.
#metadata/lv_manip.c:3442 Mirror log of 1 extents of size 8192
sectors needed for region size 4096.
#libdm-config.c:1061 Setting allocation/maximise_cling to 1
#metadata/pv_map.c:54 Allowing allocation on /dev/md1 start PE
2561 length 23039
#metadata/pv_map.c:54 Allowing allocation on /dev/md1 start PE
128000 length 347469
#metadata/lv_manip.c:2321 Parallel PVs at LE 0 length 7680:
/dev/md1
#metadata/lv_manip.c:3186 Trying allocation using contiguous
policy.
#metadata/lv_manip.c:2788 Areas to be sorted and filled
sequentially.
#metadata/lv_manip.c:2704 Still need 7681 total extents from
370508 remaining (0 positional slots):
#metadata/lv_manip.c:2707 1 (1 data/0 parity) parallel areas
of 7680 extents each
#metadata/lv_manip.c:2711 1 metadata area of 1 extents each
#metadata/lv_manip.c:2535 Not using free space on existing
parallel PV /dev/md1.
#metadata/lv_manip.c:3186 Trying allocation using cling policy.
#metadata/lv_manip.c:2783 Cling_to_allocated is set
#metadata/lv_manip.c:2786 1 preferred area(s) to be filled
positionally.
#metadata/lv_manip.c:2704 Still need 7681 total extents from
370508 remaining (1 positional slots):
#metadata/lv_manip.c:2707 1 (1 data/0 parity) parallel areas
of 7680 extents each
#metadata/lv_manip.c:2711 1 metadata area of 1 extents each
#metadata/lv_manip.c:2535 Not using free space on existing
parallel PV /dev/md1.
#metadata/lv_manip.c:3186 Trying allocation using normal
policy.
#metadata/lv_manip.c:2783 Cling_to_allocated is set
#metadata/lv_manip.c:2788 Areas to be sorted and filled
sequentially.
#metadata/lv_manip.c:2704 Still need 7681 total extents from
370508 remaining (0 positional slots):
#metadata/lv_manip.c:2707 1 (1 data/0 parity) parallel areas
of 7680 extents each
#metadata/lv_manip.c:2711 1 metadata area of 1 extents each
#metadata/lv_manip.c:2535 Not using free space on existing
parallel PV /dev/md1.
#metadata/lv_manip.c:2783 Cling_to_allocated is not set
#metadata/lv_manip.c:2788 Areas to be sorted and filled
sequentially.
#metadata/lv_manip.c:2704 Still need 7681 total extents from
370508 remaining (0 positional slots):
#metadata/lv_manip.c:2707 1 (1 data/0 parity) parallel areas
of 7680 extents each
#metadata/lv_manip.c:2711 1 metadata area of 1 extents each
#metadata/lv_manip.c:2535 Not using free space on existing
parallel PV /dev/md1.
#metadata/lv_manip.c:3220 Insufficient suitable allocatable extents
for logical volume : 7681 more required
_______________________________________________
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Mirror allocation policy
2021-01-05 21:10 ` Phillip Susi
@ 2021-01-06 1:52 ` Alasdair G Kergon
2021-01-06 14:36 ` Phillip Susi
0 siblings, 1 reply; 6+ messages in thread
From: Alasdair G Kergon @ 2021-01-06 1:52 UTC (permalink / raw)
To: Phillip Susi; +Cc: LVM general discussion and development
> #libdm-config.c:1061 Setting
> allocation/mirror_logs_require_separate_pvs to 0
So despite that, it's not letting you have the 'anywhere' for the log
part of the allocation.
However, for what you are doing, maybe you don't need an on-disk mirror
log or can temporarily borrow a little space (add small temporary
loopback PV to the VG?) for it?
> #metadata/lv_manip.c:2704 Still need 7681 total extents from
> 370508 remaining (0 positional slots):
> #metadata/lv_manip.c:2707 1 (1 data/0 parity) parallel areas
> of 7680 extents each
> #metadata/lv_manip.c:2711 1 metadata area of 1 extents each
> #metadata/lv_manip.c:2535 Not using free space on existing
> parallel PV /dev/md1.
> #metadata/lv_manip.c:3220 Insufficient suitable allocatable extents
> for logical volume : 7681 more required
Alasdair
_______________________________________________
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Mirror allocation policy
2021-01-06 1:52 ` Alasdair G Kergon
@ 2021-01-06 14:36 ` Phillip Susi
2021-01-06 14:46 ` Alasdair G Kergon
0 siblings, 1 reply; 6+ messages in thread
From: Phillip Susi @ 2021-01-06 14:36 UTC (permalink / raw)
To: Alasdair G Kergon; +Cc: LVM general discussion and development
Alasdair G Kergon writes:
> So despite that, it's not letting you have the 'anywhere' for the log
> part of the allocation.
Based on the number of extents it said it was looking for, I didn't
think it was the log that it couldn't place.
> However, for what you are doing, maybe you don't need an on-disk mirror
> log or can temporarily borrow a little space (add small temporary
> loopback PV to the VG?) for it?
I could have sworn that I had tried --corelog yesterday and it still
didn't work, but today it did. Weird.
_______________________________________________
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Mirror allocation policy
2021-01-06 14:36 ` Phillip Susi
@ 2021-01-06 14:46 ` Alasdair G Kergon
0 siblings, 0 replies; 6+ messages in thread
From: Alasdair G Kergon @ 2021-01-06 14:46 UTC (permalink / raw)
To: Phillip Susi; +Cc: LVM general discussion and development
On Wed, Jan 06, 2021 at 09:36:39AM -0500, Phillip Susi wrote:
> Based on the number of extents it said it was looking for, I didn't
> think it was the log that it couldn't place.
It was looking for what it calls 'parallel' extents i.e. extents not on
the same device as the ones belonging to the existing LV being
converted, and, at first sight, it wasn't giving you the option of
overriding that in respect of the log. Clearly the code could be
improved, but it's a very much a niche case, well outside the
normal way it's expected to be used.
Alasdair
_______________________________________________
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-01-06 14:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-05 19:31 [linux-lvm] Mirror allocation policy Phillip Susi
2021-01-05 20:47 ` Alasdair G Kergon
2021-01-05 21:10 ` Phillip Susi
2021-01-06 1:52 ` Alasdair G Kergon
2021-01-06 14:36 ` Phillip Susi
2021-01-06 14:46 ` Alasdair G Kergon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).