Re: [Gluster-devel] NFS reexport works, still stat-prefetch issues, -s problem

[Brent A Nelson]

The -s issue was completely eliminated with the recent patch.

GlusterFS is looking quite solid now, but I can still kill it with an NFS 
reexport to a slow client (100Mbps, while the servers and reexport node 
are 1000Mbps) and a 10GB file copy via NFS from the GlusterFS filesystem 
to the GlusterFS filesystem.

The glusterfs process slowly consumes more and more memory (many 10s of MB 
to several hundred MB) and eventually dies sometime before the copy 
completes (well before it would run out of memory, however).  The copy 
does work for quite a while before the glusterfs suddenly dies.  See 
attached -LDEBUG output from the glusterfs process.

The glusterfs client is using client, afr, unify, read-ahead, and 
write-behind (with aggregation of 0). glusterfsd runs with server, 
storage/posix, and posix locks (although nothing in my test should invoke 
locking).  The glusterfsd processes survive the test just fine and don't 
require a restart.

Thanks,

Brent

On Tue, 8 May 2007, Anand Avati wrote:

> does the log say "connection on <socket> still in progress - try
> later" when run with -LDEBUG?
>
> avati
>
> 2007/5/8, Brent A Nelson <address@hidden>:
> > On Sun, 6 May 2007, Anand Avati wrote:
> >
> > >> 3) When doing glusterfs -s to a different machine to retrieve the spec
> > >> file, it now fails.  A glusterfs -s to the local machine succeeds.  It
> > >> looks like a small buglet was introduced in the -s support.
> > >
> > > this is fixed now, it was an unrelated change triggered by the new way -s
> > > works.
> > >
> >
> > Hmm, my -s issue still seems to be there, a client can only seem to
> > retrieve its spec file from a local glusterfsd. Was the -s fix applied to
> > the tla repository?
> >
> > address@hidden:~# glusterfs -s jupiter01 /backup
> > glusterfs: could not open specfile
> > address@hidden:~# glusterfs -s jupiter02 /backup
> > address@hidden:~#
> >
> > The reverse on jupiter01 behaves the same way (can retrieve from itself,
> > not from jupiter02).
> >
> > The big glitch that I thought might be related (client could only mount a
> > GlusterFS if it was also a server of that GlusterFS) WAS fixed after a
> > tla update and recompile following your email, however.
> >
> > Thanks,
> >
> > Brent
>
>
> --
> Anand V. Avati

glusterfs.log
Description: Text document