Thanks Ilya, Paul. I dont have the panic traces and probably they are not related to rbd. I was merely describing our use case. On our setup that we manage, we have a software layer similar to Kubernetes CSI that orchestrates the volume map/unmap on behalf of the users. We are currently using volume locks as a way to protect the volumes from inadvertent concurrent write mounts that could lead to FS corruption as most of the volumes run with ext3/4. So in our orchestration, we take a shared on volumes that are read-only mounts, thus we can allow concurrent multiple read-only mounts, and we take exclusive lock for read-write mounts so that we can reject other RO/RW mounts while the first RW mount is in use. All this orchestration happens in a distributed manner across all our compute nodes - so it is not easy to determine when we should kick out the dead connections and claim the lock. We need to intervene manually and resolve such issues as of now. So I am looking for a way to do this deterministically. Thanks, Shridhar On Wed, 8 Apr 2020 at 02:48, Ilya Dryomov <idryomov@xxxxxxxxx> wrote: > On Tue, Apr 7, 2020 at 6:49 PM Void Star Nill <void.star.nill@xxxxxxxxx> > wrote: > > > > Hello All, > > > > Is there a way to specify that a lock (shared or exclusive) on an rbd > > volume be released if the client machine becomes unreachable or > > irresponsive? > > > > In one of our clusters, we use rbd locks on volumes to make sure provide > a > > kind of shared or exclusive access - to make sure there are no writers > when > > someone is reading and there are no readers when someone is writing. > > > > However, we often run into issues when one of the machines gets into > kernel > > panic or something and the whole pipeline gets stalled. > > What kind of kernel panics are you running into? Do you have any panic > messages or stack traces captured? > > Thanks, > > Ilya > _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |