[Gluster-users] The continuing story ...

[Mark Mielke]

On 09/18/2009 02:28 PM, Anand Avati wrote:
>> For me, it does not clear after 3 mins or 3 hours. I restarted the machines
>> at midnight, and the first time I tried again was around 1pm the next day
>> (13 hours). I easily recognize the symptoms as the /bin/mount remains in the
>> process tree. I can't get a strace -p on the /bin/mount process since it is
>> frozen. The glusterfsd process is not frozen - the glusterfs process seems
>> to be waiting on /bin/mount to complete. The only way to unfreeze the mount
>> seems to be to kill -9 /bin/mount (regular kill does not work), at which the
>> mount point goes into the disconnected state, and it is recovered using
>> unmount / remount. I tried to track down the problem before, but became
>> confused, because glusterfs seems to do it's own FUSE mount management
>> rather than using the standard (for Linux anyways?) FUSE user space
>> libraries. If my memory is correct - it seems like the process is: I run
>> mount, the mount runs /sbin/mount.glusterfs, which runs glusterfs, which
>> runs /bin/mount with the full options?
>>      
> This looks like a different issue from what I previously described. If
> you are certain that the /bin/mount which was hung was the one which
> glusterfs had spawned, then the issue might be something else. The way
> fuse based filesystems mount is 2-fold. The first 'mount -t glusterfs'
> starts /bin/mount which in turn calls /sbin/mount.glusterfs. This
> starts the glusterfs binary, which at the time of initializing the
> fuse xlator results in a call to fuse_mount() call of libfuse. libfuse
> in-turn does the second phase of mounting by calling mount -t fuse an
> in turn /sbin/mount.fuse. I'm trying to think how the three machines
> rebooting together can be correlated to the second phase fuse mount to
> hang.
>    

Thanks for looking at this. The above is compatible with my thinking. 
I'll see about getting output to prove it.

Cheers,
mark

-- 
Mark Mielke<mark at mielke.cc>