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

From: Steven J. Magnani
Date: Thu Jul 05 2012 - 16:12:01 EST


On Thu, 2012-07-05 at 12:59 +0900, OGAWA Hirofumi wrote:
> "Steve Magnani" <steve@xxxxxxxxxxxxxxx> 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>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/