On Thursday July 31, [email protected] 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
> [email protected] Intel Corporation