xfs
[Top] [All Lists]

Re: TAKE - reintroduce the nfs inode reference cache

To: Steve Lord <lord@xxxxxxx>
Subject: Re: TAKE - reintroduce the nfs inode reference cache
From: Andi Kleen <ak@xxxxxxx>
Date: Tue, 6 Mar 2001 22:23:56 +0100
Cc: Andi Kleen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx, neilb@xxxxxxxxxxxxxxx
In-reply-to: <200103062056.f26Kuo106999@xxxxxxxxxxxxxxxxxxxx>; from lord@xxxxxxx on Tue, Mar 06, 2001 at 02:56:50PM -0600
References: <ak@xxxxxxx> <200103062056.f26Kuo106999@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Tue, Mar 06, 2001 at 02:56:50PM -0600, Steve Lord wrote:
> > On Tue, Mar 06, 2001 at 02:24:43PM -0600, Steve Lord wrote:
> > > 
> > > OK, I am probably talking rubbish with this code, if someone feels like 
> > > try
> > ing
> > > it out please do and let me know if it helps. I thought I was seeing 
> > > improvements, but thinking about the code, and trying the tests again I
> > > am not seeing improvements.
> > 
> > If XFS is doing the truncate on linux inode count zeroing (in 
> > i_ops->release)
> > then it should only happen when the file is expunged from the dcache, which
> > can be never and should not happen after every NFS RPC unless the machine
> > is trashing heavily. 
> > 
> > 
> > -Andi
> 
> 
> This is f_ops release, not iops, the normal case is from close. A quick
> mod to the code to not do the release in this case but delay it until later
> appears to help. Ananth is going to test it on his 100Mbit network and we
> will see if this helps. However, should the f_ops release code be the culprit
> we may be able to find a simpler way to fix this.

I think it would be best to fix nfsd to cache file handles instead of dentries
and only do release when the nfsfh leaves the nfsfh cache.
This way could also help ext2, which caches readahead context in struct file.

Put Neil Brown into cc. Neil, do you see any obstacles with that?


-Andi


<Prev in Thread] Current Thread [Next in Thread>