Re: NFS Regression in commit 0b26a0bf6ff398

[Eric B Munson]

On Tue, 15 Feb 2011, Trond Myklebust wrote:

> On Tue, 2011-02-15 at 19:56 -0500, Eric B Munson wrote: 
> > While testing some 2.6.38 work my rsync backup script started consuming
> > large amounts of memory (all available before dying with no more available
> > memory).  I have bisected the problem back to 0b26a0bf6ff398.  I am
> > unfamiliar with the NFS code so I don't know where to start looking for a
> > possible fix.  My backups files from my home directory to an NFS mounted
> > directory.  The NFS server is a Synology DS-411+ if it matters.  Let me know
> > if there is any other information I can provide.
> 
> Exactly which 2.6.38 kernel are you running, and which NFS version?

The problem shows in the head of Linus' tree but I was able to reproduce on
vanilla 2.6.37.  I am using NFS version 3.

> 
> I'm having trouble seeing how the patch in question can be responsible
> for what you are seeing, so please could you provide more details of
> your test setup.

I have a simple backup script that rsyncs the important files from my home
directory to an NFS mounted directory on the same machine.  It is a small
home network, just a single switch between machine and file server.  The error
can be reproduced all the way back to that patch, I tested 2.6.37 looking for
a good point to start bisection and had to go back to 2.6.36 to find it.  When
it happens, my backup script stalls and the rsync process starts eating all the
free memory on the system.  There are three active rsync processes, two are
stalled in calls to select and the third is repeating a call to lstat on the
same file until rsync fails a memory allocation.

> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@xxxxxxxxxx
> www.netapp.com
>

Attachment: signature.asc
Description: Digital signature