Hello Mike, Am 15.08.19 um 19:57 schrieb Mike Christie: > >> Don't waste your time. I found a way to replicate it now. >> > > Just a quick update. > > Looks like we are trying to allocate memory in the IO path in a way that > can swing back on us, so we can end up locking up. You are probably not > hitting this with krbd in your setup because normally it's preallocating > structs, using flags like GFP_NOIO, etc. For rbd-nbd, we cannot > preallocate some structs and cannot control the allocation flags for > some operations initiated from userspace, so its possible to hit this > every IO. I can replicate this now in a second just doing a cp -r. > > It's not going to be a simple fix. We have had a similar issue for > storage daemons like iscsid and multipathd since they were created. It's > less likey to hit with them because you only hit the paths they cannot > control memory allocation behavior during recovery. > > I am looking into some things now. Great to hear, that the problem is now identified. As described I'm on vacation - if you need anything after the 8.9. we can probably invest some time to test upcoming fixes. Regards Marc -- GPG encryption available: 0x670DCBEC/pool.sks-keyservers.net _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |