--- On Fri, 11/21/08, Anand Avati <avati@xxxxxxxxxxxxx> wrote:
> > B)
> >
> > 2008-11-20 17:40:32 W
> [client-protocol.c:280:client_protocol_xfer] trans:
> > attempting to pipeline request type(2) op(4) with
> handshake
> > 2008-11-20 17:40:32 E [fuse-bridge.c:2702:init]
> glusterfs-fuse: fuse_mount
> > failed (Transport endpoint is not connected)
> >
> > 2008-11-20 17:40:32 E [glusterfs.c:547:main]
> glusterfs: Initializing FUSE
> > failed
> >
>
> The above error means there is a stale mount on /mnt.
> umount /mnt and try again.
Hmm, well to ensure that is not the case, I just
rebooted my machine. There are no mounts on /mnt
or on /mnt in the guest. I then retired only the
vnamespace -e 221 glusterfs -s 10.10.20.11 mnt
and got the same client and server errors. From
the looks of the server logs it seems like the
client attempts to connect twice, once looking
for a special config for its IP (which is
confused as the server's IP) and once without
looking for such a config. Is that correct?
Could this double attempt be the problem somehow?
Could the first attempt be leaving around a stale
mount so that the second attempt cannot succeed?
> Not quite sure about your other errors, seems not to
> be glusterfs related. Do you know if having support
> for glusterfs client to bind() to a specific local
> IP address will resolve this issue?
I assume it is actually a vserver problem, but since
I noticed the wrong IP problem, I thought that it might
be the root of the problem. No, I do not know that
binding to a specific IP will solve the mounting
problem, but as I mentioned it could potentially be
an authorization issue for me & others, and a worthwhile
switch to have in general, do you agree?
Thanks,
-Martin
