On Thursday July 31, dwmw2@xxxxxxxxxxxxx wrote: > On Fri, 2008-05-02 at 11:38 +1000, Neil Brown wrote: > > Why is there a deadlock here? I was really hoping you would answer this question. I can see the sense in your approach, but it does still seem a bit hackish. I would like to understand the details of the problem enough to be confident that there is no less-hackish solution. Thanks, NeilBrown > > Both readdir and lookup are called with i_mutex held on the directory > > so there should need to do any extra locking (he said, naively). In > > the readdirplus cases, i_mutex is held across both the readdir and the > > lookup.... > > > > One problem with your proposed solution is that filehandles aren't all > > the same length, so you cannot reliably leave space for them. > > > > Awkward. > > Yeah. I think the sanest plan for the short term is, as hch suggests, > just to transplant the existing XFS hack into the nfsd code. That way, > at least we can avoid using the hack for local users. And it makes NFS > export from other file systems (jffs2, btrfs, etc.) easier without > having to put the same hacks in each one. > > Git tree at git.infradead.org/users/dwmw2/nfsexport-2.6.git; patch > sequence follows... > > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse@xxxxxxxxx Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
