On Sun, Mar 11, 2018 at 5:10 PM, Mike Christie <mchri...@redhat.com> wrote:
> On 03/11/2018 08:54 AM, shadow_lin wrote: > > Hi Jason, > > How the old target gateway is blacklisted? Is it a feature of the target > > gateway(which can support active/passive multipath) should provide or is > > it only by rbd excusive lock? > > I think excusive lock only let one client can write to rbd at the same > > time,but another client can obtain the lock later when the lock is > released. > > For the case where we had the lock and it got taken: > > If IO was blocked, then unjammed and it has already passed the target > level checks then the IO will be failed by the OSD due to the > blacklisting. When we get IO errors from ceph indicating we are > blacklisted the tcmu rbd layer will fail the IO indicating the state > change and that the IO can be retried. We will also tell the target > layer rbd does not have the lock anymore and to just stop the iscsi > connection while we clean up the blacklisting, running commands and > update our state. > Mike, can you please give more details on how you tell the target layer rbd does not have the lock and to stop iscsi connection. Which tcmu-runner/kernel-target functions are used for that? In fact, I performed an experiment with three stale write requests stuck on blacklisted gateway, and one of them managed to overwrite newer data. I followed all instructions from http://docs.ceph.com/docs/master/rbd/iscsi-target-cli-manual-install/ and http://docs.ceph.com/docs/master/rbd/iscsi-target-cli/, so I'm interested what I'm missing... Thanks, Maxim Thanks, Maxim > >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
