Bug 915844

Summary: mount man page incorrectly describes behaviour of "relatime" mount option
Product: Red Hat Enterprise Linux 6 Reporter: Andrew Beresford <beezly>
Component: util-linux-ngAssignee: Karel Zak <kzak>
Status: CLOSED ERRATA QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.3CC: azelinka, pschiffe, psklenar
Target Milestone: rcKeywords: ManPageChange
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: The mount man page incorrectly describes "relatime" mount option. Consequence: Fix: The description of the "relatime" mount option in the mount man page has been improved to better describe when kernel updates atime. Result:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 20:45:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Andrew Beresford 2013-02-26 15:52:03 UTC
Description of problem:

The man page for mount incorrectly describes the mount option relatime;

       relatime
              Update inode access times relative to modify or change time.  Access time is only updated if the previous access time was  ear-
              lier  than  the  current  modify or change time. (Similar to noatime, but doesn’t break mutt or other applications that need to
              know if a file has been read since the last time it was modified.)

However, this is incorrect. The code in the kernel will update the atime if it is more than 24 hours later than mtime;

/*
 * With relative atime, only update atime if the previous atime is
 * earlier than either the ctime or mtime or if at least a day has
 * passed since the last atime update.
 */
static int relatime_need_update(struct vfsmount *mnt, struct inode *inode,
                             struct timespec now)
{

        if (!(mnt->mnt_flags & MNT_RELATIME))
                return 1;
        /*
         * Is mtime younger than atime? If yes, update atime:
         */
        if (timespec_compare(&inode->i_mtime, &inode->i_atime) >= 0)
                return 1;
        /*
         * Is ctime younger than atime? If yes, update atime:
         */
        if (timespec_compare(&inode->i_ctime, &inode->i_atime) >= 0)
                return 1;

        /*
         * Is the previous atime value older than a day? If yes,
         * update atime:
         */
        if ((long)(now.tv_sec - inode->i_atime.tv_sec) >= 24*60*60)
                return 1;
        /*
         * Good, we can skip the atime update:
         */
        return 0;
}

It is worth mentioning that more recent versions of the man mount page state the correct behaviour.

       relatime
              Update inode access times relative to modify or change time.  Access time is only updated if the previous access time was earlier than  the
              current  modify or change time. (Similar to noatime, but doesn't break mutt or other applications that need to know if a file has been read
              since the last time it was modified.)

              Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was  specified), and the strictatime option
              is  required  to  obtain traditional semantics. In addition, since Linux 2.6.30, the file's last access time is always  updated  if  it  is
              more than 1 day old.

(taken from util-linux 2.20.1)

Version-Release number of selected component (if applicable):

util-linux-ng-2.17.2-12.9.el6.x86_64

How reproducible:

Very :) 

Steps to Reproduce:
1. man mount
2. read entry for "relatime"
  
Actual results:

Incorrectly describes relatime option

Expected results:

Should correctly describe relatime option
Additional info:

Comment 2 RHEL Product and Program Management 2013-03-02 06:47:27 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 6 errata-xmlrpc 2013-11-21 20:45:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1648.html