Re: Documenting MS_LAZYTIME

["Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx>]

On 02/27/2015 01:04 AM, Theodore Ts'o wrote:
> On Thu, Feb 26, 2015 at 02:36:33PM +0100, Michael Kerrisk (man-pages) wrote:
>>
>>     The disadvantage of MS_STRICTATIME | MS_LAZYTIME is that
>>     in the case of a system crash, the atime and mtime fields
>>     on disk might be out of date by at most 24 hours.
> 
> I'd change to "The disadvantage of MS_LAZYTIME is that..."  and
> perhaps move that so it's clear it applies to any use of MS_LAZYTIME
> has this as a downside.
> 
> Does that make sense?

Thanks, Ted. Got it. So, now we have:

       MS_LAZYTIME (since Linux 3.20)
              Reduce  on-disk  updates  of  inode  timestamps  (atime,
              mtime, ctime) by maintaining these changes only in  memâ
              ory.  The on-disk timestamps are updated only when:

              (a)  the inode needs to be updated for some change unreâ
                   lated to file timestamps;

              (b)  the application  employs  fsync(2),  syncfs(2),  or
                   sync(2);

              (c)  an undeleted inode is evicted from memory; or

              (d)  more  than 24 hours have passed since the inode was
                   written to disk.

              This mount significantly reduces writes needed to update
              the  inode's  timestamps,  especially  mtime  and atime.
              However, in the event of a system crash, the  atime  and
              mtime  fields  on  disk might be out of date by up to 24
              hours.

              Examples of workloads where this option could be of sigâ
              nificant  benefit include frequent random writes to preâ
              allocated files, as well as cases where the  MS_STRICTAâ
              TIME  mount  option  is also enabled.  (The advantage of
              (MS_STRICTATIME |  MS_LAZYTIME)  is  that  stat(2)  will
              return  the  correctly  updated  atime,  but  the  atime
              updates will be flushed to disk only when (1) the  inode
              needs  to  be  updated for filesystem / data consistency
              reasons or (2) the inode is pushed out of memory, or (3)
              the filesystem is unmounted.)

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/