* [linux-lvm] [lvmlockd] "VG xxx lock faied: error -221" while lv operation sucess
@ 2018-07-05 9:37 Damon Wang
2018-07-09 17:18 ` David Teigland
0 siblings, 1 reply; 5+ messages in thread
From: Damon Wang @ 2018-07-05 9:37 UTC (permalink / raw)
To: LVM general discussion and development
Hi,
Sometimes I got "VG f68643c145454594871f6f51b69bf8ba lock failed:
error -221" at vg operations, likes lvcreate, while lv operation and
i/o on disks is good.
I found from this log in sanlock, vglock won't work:
2018-07-05 15:28:06 20386 [19408]: s2:r2154 resource
lvm_f68643c145454594871f6f51b69bf8ba:VGLK:/dev/mapper/f68643c145454594871f6f51b69bf8ba-lvmlock:69206016
for 3,10,19384
2018-07-05 15:28:06 20386 [19408]: r2154 cmd_acquire
3,10,19384 acquire_token -17
2018-07-05 15:28:06 20386 [19408]: cmd_acquire 3,10,19384
result -17 pid_dead 0
2018-07-05 15:28:07 20387 [19407]: cmd_acquire 2,9,19384 ci_in
2 fd 9 count 1 flags 9
2018-07-05 15:28:07 20387 [19407]: s1:r2155 resource
lvm_91c80a9e4923424a8c5526e7900b3f2e:VGLK:/dev/mapper/91c80a9e4923424a8c5526e7900b3f2e-lvmlock:69206016:SH
for 2,9,19384
2018-07-05 15:28:07 20387 [19407]: r2155 paxos_acquire begin e 0 0
2018-07-05 15:28:07 20387 [19407]: r2155 leader 2226 owner 31
2 0 dblocks 30:4456031:4456031:31:2:20386:2226:1,
2018-07-05 15:28:07 20387 [19407]: r2155 paxos_acquire leader
2226 owner 31 2 0 max mbal[30] 4456031 our_dblock 4456031 4456031 31 2
20386 2226
2018-07-05 15:28:07 20387 [19407]: r2155 paxos_acquire leader 2226 free
2018-07-05 15:28:07 20387 [19407]: r2155 ballot 2227 phase1
write mbal 4458031
2018-07-05 15:28:07 20387 [19407]: r2155 ballot 2227 phase1
read 30:4458031:0:0:0:0:2227:0,
2018-07-05 15:28:07 20387 [19407]: r2155 ballot 2227 phase2
write bal 4458031 inp 31 2 20387 q_max -1
2018-07-05 15:28:07 20387 [19407]: r2155 ballot 2227 phase2
read 30:4458031:4458031:31:2:20387:2227:0,
2018-07-05 15:28:07 20387 [19407]: r2155 ballot 2227 commit
self owner 31 2 20387
2018-07-05 15:28:07 20387 [19407]: r2155 acquire_disk rv 1
lver 2227 at 20387
2018-07-05 15:28:07 20387 [19407]: r2155 write_host_block
host_id 31 flags 1 gen 2 dblock
4458031:4458031:31:2:20387:2227:RELEASED.
2018-07-05 15:28:07 20387 [19407]: r2155 paxos_release leader
2227 owner 31 2 20387
2018-07-05 15:28:07 20387 [19407]: cmd_acquire 2,9,19384
result 0 pid_dead 0
2018-07-05 15:28:07 20387 [19408]: cmd_get_lvb ci 4 fd 14
result 0 res lvm_91c80a9e4923424a8c5526e7900b3f2e:VGLK
2018-07-05 15:28:07 20387 [19407]: cmd_acquire 2,9,19384 ci_in
2 fd 9 count 1 flags 8
2018-07-05 15:28:07 20387 [19407]: s1:r2156 resource
lvm_91c80a9e4923424a8c5526e7900b3f2e:Y2HZd7-ep4u-pead-Iuvv-B4c2-XbfR-bBjNUq:/dev/mapper/91c80a9e4923424a8c5526e7900b3f2e-lvmlock:127926272:SH
for 2,9,19384
2018-07-05 15:28:07 20387 [19407]: r2156 paxos_acquire begin e 0 0
2018-07-05 15:28:07 20387 [19407]: r2156 leader 4 owner 31 2 0
dblocks 30:6031:6031:31:2:10964:4:1,
2018-07-05 15:28:07 20387 [19407]: r2156 paxos_acquire leader
4 owner 31 2 0 max mbal[30] 6031 our_dblock 6031 6031 31 2 10964 4
2018-07-05 15:28:07 20387 [19407]: r2156 paxos_acquire leader 4 free
2018-07-05 15:28:07 20387 [19407]: r2156 ballot 5 phase1 write mbal 8031
2018-07-05 15:28:07 20387 [19407]: r2156 ballot 5 phase1 read
30:8031:0:0:0:0:5:0,
2018-07-05 15:28:07 20387 [19407]: r2156 ballot 5 phase2 write
bal 8031 inp 31 2 20387 q_max -1
2018-07-05 15:28:07 20387 [19407]: r2156 ballot 5 phase2 read
30:8031:8031:31:2:20387:5:0,
2018-07-05 15:28:07 20387 [19407]: r2156 ballot 5 commit self
owner 31 2 20387
2018-07-05 15:28:07 20387 [19407]: r2156 acquire_disk rv 1
lver 5 at 20387
2018-07-05 15:28:07 20387 [19407]: r2156 write_host_block
host_id 31 flags 1 gen 2 dblock 8031:8031:31:2:20387:5:RELEASED.
2018-07-05 15:28:07 20387 [19407]: r2156 paxos_release leader
5 owner 31 2 20387
2018-07-05 15:28:07 20387 [19407]: cmd_acquire 2,9,19384
result 0 pid_dead 0
2018-07-05 15:28:07 20387 [19408]: cmd_acquire 2,9,19384 ci_in
2 fd 9 count 1 flags 8
2018-07-05 15:28:07 20387 [19408]: s1:r2157 resource
lvm_91c80a9e4923424a8c5526e7900b3f2e:JrNEDM-pDpV-2a8c-qwfX-sJZv-ZHps-ffHB3l:/dev/mapper/91c80a9e4923424a8c5526e7900b3f2e-lvmlock:168820736
for 2,9,19384
2018-07-05 15:28:07 20387 [19408]: r2157 paxos_acquire begin a 0 0
2018-07-05 15:28:07 20387 [19408]: r2157 leader 1 owner 31 2 0
dblocks 30:31:31:31:2:20385:1:1,
2018-07-05 15:28:07 20387 [19408]: r2157 paxos_acquire leader
1 owner 31 2 0 max mbal[30] 31 our_dblock 31 31 31 2 20385 1
2018-07-05 15:28:07 20387 [19408]: r2157 paxos_acquire leader 1 free
2018-07-05 15:28:07 20387 [19408]: r2157 ballot 2 phase1 write mbal 2031
2018-07-05 15:28:07 20387 [19408]: r2157 ballot 2 phase1 read
30:2031:0:0:0:0:2:0,
2018-07-05 15:28:07 20387 [19408]: r2157 ballot 2 phase2 write
bal 2031 inp 31 2 20387 q_max -1
2018-07-05 15:28:07 20387 [19408]: r2157 ballot 2 phase2 read
30:2031:2031:31:2:20387:2:0,
2018-07-05 15:28:07 20387 [19408]: r2157 ballot 2 commit self
owner 31 2 20387
2018-07-05 15:28:07 20387 [19408]: r2157 acquire_disk rv 1
lver 2 at 20387
2018-07-05 15:28:07 20387 [19408]: cmd_acquire 2,9,19384
result 0 pid_dead 0
2018-07-05 15:28:07 20387 [19407]: cmd_release 2,9,19384 ci_in
2 fd 9 count 1 flags 0
2018-07-05 15:28:07 20387 [19407]: r2155 release_token r_flags
1 lver 2227
2018-07-05 15:28:07 20387 [19407]: r2155 write_host_block
host_id 31 flags 0 gen 0 dblock
4458031:4458031:31:2:20387:2227:RELEASED.
2018-07-05 15:28:07 20387 [19407]: r2155 release_token done r_flags 1
2018-07-05 15:28:07 20387 [19407]: cmd_release 2,9,19384
result 0 pid_dead 0 count 1
2018-07-05 15:28:08 20388 [19408]: cmd_acquire 3,10,19384
ci_in 3 fd 10 count 1 flags 9
2018-07-05 15:28:08 20388 [19408]: s2:r2158 resource
lvm_f68643c145454594871f6f51b69bf8ba:VGLK:/dev/mapper/f68643c145454594871f6f51b69bf8ba-lvmlock:69206016
for 3,10,19384
2018-07-05 15:28:08 20388 [19408]: r2158 cmd_acquire
3,10,19384 acquire_token -17
2018-07-05 15:28:08 20388 [19408]: cmd_acquire 3,10,19384
result -17 pid_dead 0
2018-07-05 15:28:08 20388 [19407]: cmd_acquire 2,9,19384 ci_in
2 fd 9 count 1 flags 9
2018-07-05 15:28:08 20388 [19407]: s1:r2159 resource
lvm_91c80a9e4923424a8c5526e7900b3f2e:VGLK:/dev/mapper/91c80a9e4923424a8c5526e7900b3f2e-lvmlock:69206016:SH
for 2,9,19384
Meantime lvmlockctl -d:
1530775686 recv lvcreate[5615] cl 1889 lock vg
"f68643c145454594871f6f51b69bf8ba" mode ex flags 0
1530775686 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK action lock ex
1530775686 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK
res_lock cl 1889 mode ex
1530775686 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK
lock_san ex at /dev/mapper/f68643c145454594871f6f51b69bf8ba-lvmlock:69206016
1530775686 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK
lock_san acquire error -17
1530775686 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK
res_lock rv -221 read vb 0 0 0
1530775686 send lvcreate[5615] cl 1889 lock vg rv -221
1530775686 close lvcreate[5615] cl 1889 fd 9
1530775686 new cl 1890 pi 2 fd 9
1530775686 new cl 1891 pi 3 fd 12
1530775687 recv lvchange[5624] cl 1890 lock vg
"91c80a9e4923424a8c5526e7900b3f2e" mode sh flags 0
1530775687 S lvm_91c80a9e4923424a8c5526e7900b3f2e R VGLK action lock sh
1530775687 S lvm_91c80a9e4923424a8c5526e7900b3f2e R VGLK
res_lock cl 1890 mode sh
1530775687 S lvm_91c80a9e4923424a8c5526e7900b3f2e R VGLK
lock_san sh at /dev/mapper/91c80a9e4923424a8c5526e7900b3f2e-lvmlock:69206016
1530775687 S lvm_91c80a9e4923424a8c5526e7900b3f2e R VGLK
res_lock rv 0 read vb 101 0 344
1530775687 send lvchange[5624] cl 1890 lock vg rv 0
1530775687 recv lvchange[5624] cl 1890 lock lv
"91c80a9e4923424a8c5526e7900b3f2e" mode sh flags 1
1530775687 S lvm_91c80a9e4923424a8c5526e7900b3f2e R
Y2HZd7-ep4u-pead-Iuvv-B4c2-XbfR-bBjNUq action lock sh
1530775687 S lvm_91c80a9e4923424a8c5526e7900b3f2e R
Y2HZd7-ep4u-pead-Iuvv-B4c2-XbfR-bBjNUq res_lock cl 1890 mode sh
(bd6553925764483b96781d0d11f4d385)
1530775687 S lvm_91c80a9e4923424a8c5526e7900b3f2e R
Y2HZd7-ep4u-pead-Iuvv-B4c2-XbfR-bBjNUq lock_san sh at
/dev/mapper/91c80a9e4923424a8c5526e7900b3f2e-lvmlock:127926272
1530775687 S lvm_91c80a9e4923424a8c5526e7900b3f2e R
Y2HZd7-ep4u-pead-Iuvv-B4c2-XbfR-bBjNUq res_lock rv 0
1530775687 send lvchange[5624] cl 1890 lock lv rv 0
My environment:
[root@iscsi ~]# rpm -qa | grep -E 'lvm|san'
lvm2-libs-2.02.177-4.el7.x86_64
lvm2-2.02.177-4.el7.x86_64
sanlock-3.6.0-1.el7.x86_64
lvm2-lockd-2.02.177-4.el7.x86_64
sanlock-lib-3.6.0-1.el7.x86_64
I have tried stop lock and start again, but still error -221
Thanks,
Damon
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [linux-lvm] [lvmlockd] "VG xxx lock faied: error -221" while lv operation sucess
2018-07-05 9:37 [linux-lvm] [lvmlockd] "VG xxx lock faied: error -221" while lv operation sucess Damon Wang
@ 2018-07-09 17:18 ` David Teigland
2018-07-10 7:52 ` Damon Wang
0 siblings, 1 reply; 5+ messages in thread
From: David Teigland @ 2018-07-09 17:18 UTC (permalink / raw)
To: Damon Wang; +Cc: linux-lvm
On Thu, Jul 05, 2018 at 05:37:57PM +0800, Damon Wang wrote:
> Hi,
>
> Sometimes I got "VG f68643c145454594871f6f51b69bf8ba lock failed:
> error -221" at vg operations, likes lvcreate, while lv operation and
> i/o on disks is good.
It looks like the lock was acquired but not released for some reason,
so subsequent attempts to acquire it are failing. There are a couple
things you could send that might narrow down what happened:
- Anything from /var/log/messages (or /var/log/sanlock.log) related
to that lock.
- 'sanlock status' which will probably show that it's still held.
> I have tried stop lock and start again, but still error -221
That was the right idea. Stop was probably ignored (because it thought
the lockspace/vg was busy). I'll try some possible workarounds and send
you a suggestion based on that.
Dave
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] [lvmlockd] "VG xxx lock faied: error -221" while lv operation sucess
2018-07-09 17:18 ` David Teigland
@ 2018-07-10 7:52 ` Damon Wang
2018-07-10 14:11 ` David Teigland
0 siblings, 1 reply; 5+ messages in thread
From: Damon Wang @ 2018-07-10 7:52 UTC (permalink / raw)
To: David Teigland; +Cc: LVM general discussion and development
Hi dave,
Thank you for your reply, unfortunately I have rebooted that host last stat :(
But good news is I have saved some logs, but I don't know weather it
helps since I only saved "lvmlockctl -i", "sanlock client status",
sanlock.log and messages.
I pasted "sanlock client status" on https://pastebin.com/M9TRKeBk
"lvmlockctl -i ": https://pastebin.com/v9E1Atig
Related messages and sanlock.log:
"messages": https://pastebin.com/1tqtQvDS
"sanlock.log": https://pastebin.com/ESA4Wz3B
Thanks!
Damon
David Teigland <teigland@redhat.com> 于2018年7月10日周二 上午1:19写道：
>
> On Thu, Jul 05, 2018 at 05:37:57PM +0800, Damon Wang wrote:
> > Hi,
> >
> > Sometimes I got "VG f68643c145454594871f6f51b69bf8ba lock failed:
> > error -221" at vg operations, likes lvcreate, while lv operation and
> > i/o on disks is good.
>
> It looks like the lock was acquired but not released for some reason,
> so subsequent attempts to acquire it are failing. There are a couple
> things you could send that might narrow down what happened:
>
> - Anything from /var/log/messages (or /var/log/sanlock.log) related
> to that lock.
>
> - 'sanlock status' which will probably show that it's still held.
>
> > I have tried stop lock and start again, but still error -221
>
> That was the right idea. Stop was probably ignored (because it thought
> the lockspace/vg was busy). I'll try some possible workarounds and send
> you a suggestion based on that.
>
> Dave
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] [lvmlockd] "VG xxx lock faied: error -221" while lv operation sucess
2018-07-10 7:52 ` Damon Wang
@ 2018-07-10 14:11 ` David Teigland
2018-07-11 3:07 ` Damon Wang
0 siblings, 1 reply; 5+ messages in thread
From: David Teigland @ 2018-07-10 14:11 UTC (permalink / raw)
To: Damon Wang; +Cc: linux-lvm
On Tue, Jul 10, 2018 at 03:52:26PM +0800, Damon Wang wrote:
> Hi dave,
>
> Thank you for your reply, unfortunately I have rebooted that host last stat :(
>
> But good news is I have saved some logs, but I don't know weather it
> helps since I only saved "lvmlockctl -i", "sanlock client status",
> sanlock.log and messages.
>
> I pasted "sanlock client status" on https://pastebin.com/M9TRKeBk
> "lvmlockctl -i ": https://pastebin.com/v9E1Atig
>
> Related messages and sanlock.log:
>
> "messages": https://pastebin.com/1tqtQvDS
> "sanlock.log": https://pastebin.com/ESA4Wz3B
That's all that's needed. sanlock was getting io timeouts (-202) from the
storage (probably related to the qla errors you also see.) sanlock uses a
10 second io timeout by default (although using a non default value has
not been as thoroughly tested.)
Here's the first timeout, while trying to acquire a lock:
Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 ballot 2 dblock read2 error -202
Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 ballot 2 retract error -210
Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 paxos_acquire 2 ballot error -210
Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 acquire_token disk error -210 RETRACT_PAXOS
Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 paxos_release already free last lver 1 owner 31 1 0 writer 31 1 20359 disk lver 1 owner 31 1 0 writer 31 1 20359
Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 cmd_acquire 3,10,19384 acquire_token -210 lease io error
Jul 5 15:27:49 iscsi lvmlockd[19384]: 1530775669 S lvm_f68643c145454594871f6f51b69bf8ba R 4bPTER-Q21t-VedL-UM8w-dPgn-6S13-lPoaB4 lock_san acquire error -210
Here's the second, while trying to release a lock:
Jul 5 15:27:59 iscsi sanlock[19403]: 2018-07-05 15:27:59 20379 [19407]: r2135 write_host_block host_id 31 flags 0 gen 0 rv -202
Jul 5 15:27:59 iscsi sanlock[19403]: 2018-07-05 15:27:59 20379 [19407]: r2135 release_token shared write_host_block -202
Jul 5 15:27:59 iscsi sanlock[19403]: 2018-07-05 15:27:59 20379 [19407]: r2135 release_token timeout r_flags 1
Jul 5 15:27:59 iscsi lvmlockd[19384]: 1530775679 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK unlock_san release error -202
Jul 5 15:27:59 iscsi lvmlockd[19384]: 1530775679 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK res_unlock lm error -221
Jul 5 15:28:02 iscsi kernel: qla2xxx [0000:05:00.1]-801c:7: Abort command issued nexus=7:4:3 -- 1 2002.
Jul 5 15:28:04 iscsi kernel: qla2xxx [0000:05:00.1]-801c:7: Abort command issued nexus=7:4:0 -- 1 2002.
The io timeout error during acquire is usually not a problem, because the
command will retry and succeed, or fail cleanly. The io timeout error
during release is a bigger problem, because it leaves a stray lock that
later interferes with trying to acquire the lock again (the -17 errors you
get after this.) It looks like lvmlockd needs to better handle io timeout
errors during unlock. Thanks for the info,
Dave
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] [lvmlockd] "VG xxx lock faied: error -221" while lv operation sucess
2018-07-10 14:11 ` David Teigland
@ 2018-07-11 3:07 ` Damon Wang
0 siblings, 0 replies; 5+ messages in thread
From: Damon Wang @ 2018-07-11 3:07 UTC (permalink / raw)
To: David Teigland; +Cc: LVM general discussion and development
Hi Dave,
Thanks a lot for your analysis, and with help of
http://people.redhat.com/teigland/sanlock-messages.txt , It's clear to
get what happened.
So there must be some storage problem on Jul 5 15:27, hope lvmlockd
can handle this situation better in the future :-D
Thanks again,
Damon
On Tue, Jul 10, 2018 at 10:11 PM David Teigland <teigland@redhat.com> wrote:
>
> On Tue, Jul 10, 2018 at 03:52:26PM +0800, Damon Wang wrote:
> > Hi dave,
> >
> > Thank you for your reply, unfortunately I have rebooted that host last stat :(
> >
> > But good news is I have saved some logs, but I don't know weather it
> > helps since I only saved "lvmlockctl -i", "sanlock client status",
> > sanlock.log and messages.
> >
> > I pasted "sanlock client status" on https://pastebin.com/M9TRKeBk
> > "lvmlockctl -i ": https://pastebin.com/v9E1Atig
> >
> > Related messages and sanlock.log:
> >
> > "messages": https://pastebin.com/1tqtQvDS
> > "sanlock.log": https://pastebin.com/ESA4Wz3B
>
> That's all that's needed. sanlock was getting io timeouts (-202) from the
> storage (probably related to the qla errors you also see.) sanlock uses a
> 10 second io timeout by default (although using a non default value has
> not been as thoroughly tested.)
>
> Here's the first timeout, while trying to acquire a lock:
>
> Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 ballot 2 dblock read2 error -202
> Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 ballot 2 retract error -210
> Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 paxos_acquire 2 ballot error -210
> Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 acquire_token disk error -210 RETRACT_PAXOS
> Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 paxos_release already free last lver 1 owner 31 1 0 writer 31 1 20359 disk lver 1 owner 31 1 0 writer 31 1 20359
> Jul 5 15:27:49 iscsi sanlock[19403]: 2018-07-05 15:27:49 20369 [19408]: r2136 cmd_acquire 3,10,19384 acquire_token -210 lease io error
> Jul 5 15:27:49 iscsi lvmlockd[19384]: 1530775669 S lvm_f68643c145454594871f6f51b69bf8ba R 4bPTER-Q21t-VedL-UM8w-dPgn-6S13-lPoaB4 lock_san acquire error -210
>
> Here's the second, while trying to release a lock:
>
> Jul 5 15:27:59 iscsi sanlock[19403]: 2018-07-05 15:27:59 20379 [19407]: r2135 write_host_block host_id 31 flags 0 gen 0 rv -202
> Jul 5 15:27:59 iscsi sanlock[19403]: 2018-07-05 15:27:59 20379 [19407]: r2135 release_token shared write_host_block -202
> Jul 5 15:27:59 iscsi sanlock[19403]: 2018-07-05 15:27:59 20379 [19407]: r2135 release_token timeout r_flags 1
> Jul 5 15:27:59 iscsi lvmlockd[19384]: 1530775679 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK unlock_san release error -202
> Jul 5 15:27:59 iscsi lvmlockd[19384]: 1530775679 S lvm_f68643c145454594871f6f51b69bf8ba R VGLK res_unlock lm error -221
> Jul 5 15:28:02 iscsi kernel: qla2xxx [0000:05:00.1]-801c:7: Abort command issued nexus=7:4:3 -- 1 2002.
> Jul 5 15:28:04 iscsi kernel: qla2xxx [0000:05:00.1]-801c:7: Abort command issued nexus=7:4:0 -- 1 2002.
>
> The io timeout error during acquire is usually not a problem, because the
> command will retry and succeed, or fail cleanly. The io timeout error
> during release is a bigger problem, because it leaves a stray lock that
> later interferes with trying to acquire the lock again (the -17 errors you
> get after this.) It looks like lvmlockd needs to better handle io timeout
> errors during unlock. Thanks for the info,
> Dave
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-11 3:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-05 9:37 [linux-lvm] [lvmlockd] "VG xxx lock faied: error -221" while lv operation sucess Damon Wang
2018-07-09 17:18 ` David Teigland
2018-07-10 7:52 ` Damon Wang
2018-07-10 14:11 ` David Teigland
2018-07-11 3:07 ` Damon Wang
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).