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 <brent@xxxxxxxxxxxx>:
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 <brent@xxxxxxxxxxxx>: >> 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? >> >> root@jupiter02:~# glusterfs -s jupiter01 /backup >> glusterfs: could not open specfile >> root@jupiter02:~# glusterfs -s jupiter02 /backup >> root@jupiter02:~# >> >> 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
