Hi, With a change of configuration on the server followed by a server process restart, I've seen this behavior, which I don't recall seeing with 1.3 : [2009-05-28 10:29:32] N [client-protocol.c:6248:notify] filedata: disconnected [2009-05-28 10:29:32] E [socket.c:744:socket_connect_finish] filedata: connection to 192.168.168.231:6997 failed (Connection refused) [2009-05-28 10:29:32] E [socket.c:744:socket_connect_finish] filedata: connection to 192.168.168.231:6997 failed (Connection refused) [2009-05-28 10:29:36] W [fuse-bridge.c:1837:fuse_statfs_cbk] glusterfs-fuse: 225: ERR => -1 (Transport endpoint is not connected) [2009-05-28 10:29:36] C [fuse-bridge.c:2553:notify] fuse: Remote volume file changed, try re-mounting. [2009-05-28 10:29:36] W [glusterfsd.c:827:cleanup_and_exit] glusterfs: shutting down [2009-05-28 10:29:36] N [fuse-bridge.c:2843:fini] fuse: Unmounting '/mnt/file01'. [2009-05-28 10:29:36] W [glusterfsd.c:827:cleanup_and_exit] glusterfs: shutting down [2009-05-28 10:30:15] W [socket.c:1319:socket_init] trans: disabling non-blocking IO [2009-05-28 10:30:15] W [socket.c:1319:socket_init] trans: disabling non-blocking IO What happened was that I restarted the server, at which point the client process went away. It seems like it exited alone, without trying to remount but just unmounted... is this expected? Matthias Ioannis Aslanidis wrote : > Can this affect currently connected clients and make them get > disconnected or lose the connection to the server (that is the main > problem we are experiencing every now and then)? > > Amar Tumballi wrote: > > I already send this message along with tons of others, but > > particularly for this one, can anyone explain why the error message > > says that the volume file got modified? How can this happen? How can > > this be prevented or be worked around? > > > > > > There is an option in GlusterFS where the client can pull a volume file > > from server (so the management of volumefile becomes easier). Assume you > > have 5 clients, which are already mounted with '-s' option and now, you > > modify the client's volume file on server, and now mount another client. > > This can cause a confusion in the filesystem in most of the cases as > > client volumefiles can be different. (Assume a case where first 5 client > > uses 'cluster/stripe' and the newer client uses 'cluster/replicate'). > > This timestamp check of volume file is present to prevent this behavior. > > > > > > [server-protocol.c:6553:_volfile_update_checksum] foo-server: the volume > > file got modified between earlier access and now, this may lead to > > inconsistency between clients, advised to remount client > > > > > > > > The error clearly advises to remount the client, but why? > > > > > > Remount the connected clients. That means, the volume file used by those > > clients are no more valid, and when every client fetches new volumefile > > from server, things work fine. > > > > > > If you want to disable the volumefile checksum on server, you can provide > > > > "option verify-volfile-checksum off" > > > > in server protocol volume. > > > > Regards, > > > > -- > > Amar Tumballi > > -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 10 (Cambridge) - Linux kernel 2.6.27.21-170.2.56.fc10.x86_64 Load : 0.30 0.58 0.58
