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

[Anand Avati]

Brent,
 actually it just may be your 'connect()' is slow, run a 'telnet
<server> <ip>' to glusterfsd and see how fast/slow you get the

Connected to <server>
Escape character is '^]'.

the connect() delay may be due to lot of reasons and not just low
'physical' link. I'm sure the throughputs will be just fine.

avati

2007/5/8, Brent A Nelson <address@hidden>:
> Yep, that is it.  I see you have a patch in the tla (although it mentions
> slow links, whereas mine is gigabit-to-gigabit on the same switch); I'll
> see how that works...
>
> 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
> >


--
Anand V. Avati