Hello Omar,
On 02/27/2015 09:08 AM, Omar Sandoval wrote:
> 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:
>>> 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
> "This mount option"?
Thanks, fixed.
>> 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?
Good point. I replaced this piece with just a few words referring
to the list above.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
|