Description of problem:
For GFS2 filesystems, in the 5.4 official documentation, there is a mount option "relatime":
But it seems to not work:
# mount /dev/... /mnt -o relatime
/sbin/mount.gfs2: error mounting /dev/..... on /mnt: Invalid argument
Version-Release number of selected component (if applicable):
Is an error in the documentation or I have a misconfiguration in my system?
Thanks & Best Regards
I looked into this issue and as far as I can tell, the documentation
is wrong. The "relatime" mount option was not added to the Linux
kernel until 2.6.20. Since Red Hat Enterprise Linux 5 is based on
the 2.6.18 kernel, it does not include the option. I'm reassigning
this bug to Steven Levine to have the documentation fixed. Thanks
for pointing out the problem.
I'd also like to note that Red Hat Enterprise Linux 6 is now, I
believe, in beta. Since it's based on a more recent kernel, I tried
the "-o relatime" there and the mount option seemed to work
correctly, although I didn't test the actual function of what
Red Hat File Systems
As background here: I added the relatime information during a GFS2 review. Steve Whitehouse had written the following, in December of 2008:
> atime_quantum has gone, in its place we support the noatime and relatime
> > mount options, as per other filesystems. We recommend relatime to get
> > similar behaviour to gfs1. The "normal" atime mode has been improved to
> > reduce the number of write I/Os generated by atime updated compared with
> I'm glad you noted this, because I had a section in the document about
> using atime_quantum, which I've now eliminated. I also didn't know about
> support for relatime. I've replaced the section on atime_quantum with
> the following. Does this look correct? (It's based on the existing
> section on noatime.)
I sent the new section to Steve and he said it looked good.
So that's how this section got into the GFS2 document. I don't know, though, if it's a problem that the option is not supported -- with the normal atime behavior improved it may not be. Bob Peterson is checking into this.
In GFS there was always a problem with atime updates in that if cluster members has differing clocks, then they could potentially fight over updating the time stamp of an inode open on multiple cluster members.
The GFS2 system insists on a monotonically increasing atime, so that the cluster member with the clock which is most ahead will set the atime and it will not be updated until such time as the other cluster members' clocks' catch up with the current atime setting. That greatly reduces the number of updates which are likely to occur when the clocks differ slightly.
relatime is only for RHEL6 and up. Sorry if I made a mistake earlier. The noatime option is supported in all cases. The nodiratime option is supported with GFS2. It might also be supported with some more recent GFS kernels too. I'd need to check on that to be certain. The problem was the change in the VFS layer which changed the way in which atime worked, basically forcing all filesystems to adopt the VFS way of doing things. That was ok for GFS2, but I remember it causing some issues with GFS when it occurred.
I have removed the documentaton for relatime from my working RHEL 5 draft of the GFS2 document and the updated, corrected document should be part of the RHEL 5.6 release.