Are you sure this could be done earlier?

I tested with 3.1, 3.2 and 3.3 (latest git branches). All of them don't support noatime. The mount.glusterfs script in 3.1 and 3.2 just dropped the unknown options passed with -o silently. The mount script was reworked in 3.3, so that it makes some noise about unknown options.

In 3.3, I also tried forcibly adding a "noatime" option by adding it to the mnt_args string in the source code. (fuse-bridge.c, the init() function). This lead to mount failures with a normal build. Looks like the fuse-lib used by gluster doesn't support "noatime" as an option. I tried a build with fusermount enabled (using --enable-fusermount with the configure script). It was only with this that mount succeeded. Then tried forcibly adding a "nodiratime" option. This option caused both normal and fusermount mounts to fail.

So it looks like gluster never supported these two options out of the box!

Regards,
Kaushal

Although I've had that in my mount options forever, no. I don't know that it was working.

I've changed this to an enhancement request.

For those Volumes where you want noatime and nodiratime, why not set those mount options on the Bricks?

for now, the best option is what Andrew (comment #3) suggested. will keep this open for some time to see if there is a possibility in glusterfs to not to bother about time.

*bump* The fun part of this issue is that if you do set nodiratime, glusterfs 3.4 mounts just break with no clear error. More confusingly, the trace error you do end up with is

[2014-05-29 04:58:33.129366] E [mount.c:162:fuse_mount_fusermount] 0-glusterfs-fuse: failed to exec fusermount: No such file or directory

Wat.

because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.