Bug 606224
Summary: | GFS2 option relatime | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Davide Brunato <brunato> |
Component: | Documentation-cluster | Assignee: | Steven J. Levine <slevine> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Cluster QE <mspqa-list> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 5.4 | CC: | edamato, kzak, mhideo, rpeterso, swhiteho |
Target Milestone: | rc | Keywords: | Documentation |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-04-14 04:49:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Davide Brunato
2010-06-21 07:12:41 UTC
Hi Davide, 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 "relatime" does. Regards, Bob Peterson 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 > >gfs1. I responded: > 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. |