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/
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
