On Fri, Feb 27, 2015 at 09:01:10AM +0100, Michael Kerrisk (man-pages) wrote:

On 02/27/2015 01:04 AM, Theodore Ts'o wrote:

quoted

On Thu, Feb 26, 2015 at 02:36:33PM +0100, Michael Kerrisk (man-pages) wrote:

quoted

    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

"This mount option"?

              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.)

Is it necessary to repeat the reasons for flushing, which are stated
above?

Cheers,

Michael


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

_______________________________________________
xfs mailing list
xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org
http://oss.sgi.com/mailman/listinfo/xfs

Thanks!
-- 
Omar