[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gluster-devel] Problem with autofs configuration - sometimes mount does

From: Mark Mielke
Subject: [Gluster-devel] Problem with autofs configuration - sometimes mount does not complete fast enough?
Date: Sun, 06 Sep 2009 22:42:17 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3

This seems to happen about 50% of the time:

address@hidden ~]# ls /gluster/data
ls: cannot open directory /gluster/data: No such file or directory
address@hidden ~]# ls /gluster/data
00  15  32  47  64  07  24  41  56
01  16  33  50  65  10  25  42  57
02  17  34  51  66  11  26  43  60
03  20  35  52  67  12  27  44  61
04  21  36  53  lost+found  13  30  45  62
05  22  37  54  14  31  46  63
06  23  40  55

If the mount is not up at the time of accessing the autofs directory, then 50% of the time it takes 3 to 5 seconds for the directory listing to show properly, and the other 50% of the time it takes the same 3 to 5 seconds but gives a "No such file or directory" error. This happens whether a longer path (/gluster/data/44 for example) or just the top level path is used. This happens whether autofs --ghost is used or not. It seems like something might time out too soon if glusterfs takes too long to start?

Here are the relevant autofs configurations:

address@hidden ~]# head -1 /etc/auto.master
/gluster /etc/glusterfs/auto.gluster --timeout=3600

address@hidden ~]# cat /etc/glusterfs/auto.gluster
data -fstype=glusterfs :/etc/glusterfs/gluster-data.vol

For gluster-data.vol, it is to a 3-node cluster/replicate cluster with some of the performance/ modules activated.

Any suggestions?

I don't mind the autofs mount taking a few seconds to complete (although if 3 to 5 seconds is unusual, perhaps I can fix that as well). I AM concerned that if the autofs mount is used for the first time, or the first time after a period of inactivity, that the request might spuriously fail. This is bad. Is this AutoFS at fault or is it GlusterFS?

My current guess is that GlusterFS is saying the mount is complete to AutoFS before the actual mount operation takes effect. 50% of the time GlusterFS is able to complete the mount before AutoFS let's the user continue, and all is well. The other 50% of the time, GlusterFS does not quite finish the mount, and AutoFS gives the user a broken directory.

I might try and prove this by adding a sleep 5 to /sbin/mount.glusterfs, although I do not consider this a valid solution, as it just reduces the effect of the race - it does not eliminate the race.


Mark Mielke<address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]