Re: [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries

["Steven J. Magnani" <steve@digidescorp.com>]

On Thu, 2012-07-05 at 12:59 +0900, OGAWA Hirofumi wrote: 
> "Steve Magnani" <steve@digidescorp.com> writes:
> > I may yet rip out the get_name code. The testing I did before posting the 
> > patch seemed to indicate that it was needed - I saw ESTALE errors without 
> > get_name support that I did not see with it present. But I've been 
> > digging into this some more and I think that was just a coincidence; 
> > probably I just generated more extreme memory pressure when testing 
> > without get_name. I should know more tomorrow.

The get_name code can go away.

It turns out that it is much harder to generate severe memory pressure
in my virtual 3.5 kernel than in my embedded 2.6.35 kernel.
fat_reconstitute_inode() was not being exercised in 3.5 as much as I
thought.

And, there was a change made in 3.5
(b0b0382bb4904965a9e9fca77ad87514dfda0d1c) that causes the parent
i_logstart field not to be populated when building NFS file handles for
shares marked 'no_subtree_check'. That causes fat_reconstitute_inode()
to fail, because it interprets the parent of such objects as 'root'
rather than as 'unknown'.

I'm reworking the patch to cope with the 'unknown' case, and to address
your other comments. Still need to look into lock_super() vs.
inode->i_mutex.

Steve
------------------------------------------------------------------------
Steven J. Magnani               "I claim this network for MARS!
www.digidescorp.com              Earthling, return my space modulator!"

#include <standard.disclaimer>