Re: rbd rm snap on image with exclusive lock

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

 



On 17-10-25 02:39 PM, Jason Dillaman wrote:
That log is showing that a snap remove request was made from a client
that couldn't acquire the lock to a client that currently owns the
lock. The client that currently owns the lock responded w/ an -ENOENT
error that the snapshot doesn't exist. Depending on the maintenance
operation requested, different errors codes are filtered out to handle
the case where Ceph double (or more) delivers the request message to
the lock owner. Normally this isn't an issue since the local client
pre-checks the image state before sending the RPC message (i.e. snap
remove will first locally ensure the snap exists and respond w/
-ENOENT if it doesn't).

Therefore, in this case, the question is who is this rogue client that
still owns the lock and is responding the a snap remove request but
hasn't refreshed its state to know that the snapshot exists.

Thanks, that makes things clear.

Seems like we have some Cinders utilizing Infernalis (9.2.1) librbd. Are you aware of any bugs in 9.2.x that could cause such behavior? We've seen that for the first time...

--
Piotr Dałek
piotr.dalek@xxxxxxxxxxxx
https://www.ovh.com/us/
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux