On Thu, Jan 20, 2011 at 9:27 AM, Yehuda Sadeh Weinraub <yehudasa@xxxxxxxxx> wrote: > On Tue, Jan 18, 2011 at 2:42 PM, Nick Piggin <npiggin@xxxxxxxxx> wrote: >> On Wed, Jan 19, 2011 at 9:32 AM, Yehuda Sadeh Weinraub > >>> There's an issue with ceph as it references the >>> dentry->d_parent(->d_inode) at dentry_release(), so setting >>> dentry->d_parent to NULL here doesn't work with ceph. Though there is >>> some workaround for it, we would like to be sure that this one is >>> really required so that we don't exacerbate the ugliness. The >>> workaround is to keep a pointer to the parent inode in the private >>> dentry structure, which will be referenced only at the .release() >>> callback. This is clearly not ideal. >> >> Hmm, I'll have to think about it. Probably we can check for >> d_count == 0 rather than parent != NULL I think? >> > > That'll solve ceph's problem, don't know about how'd affect other > stuff. We'll need to know whether this is the solution, or whether > we'd need to introduce some other band aid fix. No I think it will work fine. Basically we just need to know whether we have been deleted, and if so then we restart rather than walking back up the parent. I'll send a patch in a few days. For the meantime, it's a rathe small window for ceph to worry about. So we'll have something before -rc2 which should be OK. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
