Documenting MS_LAZYTIME

Documenting MS_LAZYTIME

[Michael Kerrisk]

Hello Ted,

Based on your commit message 0ae45f63d4e, I I wrote the documentation
below for MS_LAZYTIME, to go into the mount(2) man page. Could you
please check it over and let me know if it's accurate. In particular,
I added pieces marked with "*" below that were not part of the commit
message and I'd like confirmation that they're accurate.

Thanks,

Michael

[[
       MS_LAZYTIME (since Linux 3.20)
              Only  update  filetimes (atime, mtime, ctime) on the in-
              memory version of the file  inode.   The  on-disk  time‐
              stamps 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 i-node was
*                  written to disk.

              This mount option significantly reduces  writes  to  the
              inode  table  for workloads that perform frequent random
              writes to preallocated files.

*             As at Linux 3.20, this option is supported only on ext4.
]]

-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Documenting MS_LAZYTIME

[Andreas Dilger]

On Feb 20, 2015, at 1:50 AM, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> Hello Ted,
> 
> Based on your commit message 0ae45f63d4e, I I wrote the documentation
> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
> please check it over and let me know if it's accurate. In particular,
> I added pieces marked with "*" below that were not part of the commit
> message and I'd like confirmation that they're accurate.
> 
> Thanks,
> 
> Michael
> 
> [[
>       MS_LAZYTIME (since Linux 3.20)
>              Only  update  filetimes (atime, mtime, ctime) on the in-
>              memory version of the file  inode.   The  on-disk  time‐
>              stamps 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 i-node was
> *                  written to disk.
> 
>              This mount option significantly reduces  writes  to  the
>              inode  table  for workloads that perform frequent random
>              writes to preallocated files.
> 
> *             As at Linux 3.20, this option is supported only on ext4.

I _think_ that the lazytime mount option is generic for all filesystems.
I believe ext4 has an extra optimization for it, but that's it.

Cheers, Andreas

Re: Documenting MS_LAZYTIME

[Michael Kerrisk (man-pages)]

On 20 February 2015 at 13:32, Andreas Dilger <adilger@dilger.ca> wrote:
> On Feb 20, 2015, at 1:50 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>
>> Hello Ted,
>>
>> Based on your commit message 0ae45f63d4e, I I wrote the documentation
>> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
>> please check it over and let me know if it's accurate. In particular,
>> I added pieces marked with "*" below that were not part of the commit
>> message and I'd like confirmation that they're accurate.
>>
>> Thanks,
>>
>> Michael
>>
>> [[
>>       MS_LAZYTIME (since Linux 3.20)
>>              Only  update  filetimes (atime, mtime, ctime) on the in-
>>              memory version of the file  inode.   The  on-disk  time‐
>>              stamps 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 i-node was
>> *                  written to disk.
>>
>>              This mount option significantly reduces  writes  to  the
>>              inode  table  for workloads that perform frequent random
>>              writes to preallocated files.
>>
>> *             As at Linux 3.20, this option is supported only on ext4.
>
> I _think_ that the lazytime mount option is generic for all filesystems.
> I believe ext4 has an extra optimization for it, but that's it.

Ah yes, looking at the code again, that makes sense. I think you're
right, and I've struck that last sentence. Thanks, Andreas.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Documenting MS_LAZYTIME

[Eric Sandeen]

On 2/20/15 2:50 AM, Michael Kerrisk wrote:
> Hello Ted,
> 
> Based on your commit message 0ae45f63d4e, I I wrote the documentation
> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
> please check it over and let me know if it's accurate. In particular,
> I added pieces marked with "*" below that were not part of the commit
> message and I'd like confirmation that they're accurate.
> 
> Thanks,
> 
> Michael
> 
> [[
>        MS_LAZYTIME (since Linux 3.20)
>               Only  update  filetimes (atime, mtime, ctime) on the in-
>               memory version of the file  inode.   The  on-disk  time‐
>               stamps are updated only when:

"filetimes" and "file inode" seems a bit awkward.  How about:

>        MS_LAZYTIME (since Linux 3.20)
>		Reduce on-disk updates of inode timestamps (atime, mtime, ctime)
> 		by maintaining these changes only in memory, unless:

(maybe I'm bike-shedding too much, if so, sorry).

>               (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 i-node was
> *                  written to disk.

Please don't use "i-node" - simply "inode" is much more common in the manpages
AFAICT.

>               This mount option significantly reduces  writes  to  the
>               inode  table  for workloads that perform frequent random
>               writes to preallocated files.

This seems like an overly specific description of a single workload out
of many which may benefit, but what do others think?  "inode table" is also
fairly extN-specific.

-Eric
 
> *             As at Linux 3.20, this option is supported only on ext4.
> ]]
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Documenting MS_LAZYTIME

[Theodore Ts'o]

On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
> 
> >               This mount option significantly reduces  writes  to  the
> >               inode  table  for workloads that perform frequent random
> >               writes to preallocated files.
> 
> This seems like an overly specific description of a single workload out
> of many which may benefit, but what do others think?  "inode table" is also
> fairly extN-specific.

How about somethign like "This mount significantly reduces writes
needed to update the inode's timestamps, especially mtime and actime.
Examples of workloads where this could be a large win include frequent
random writes to preallocated files, as well as cases where the
MS_STRICTATIME mount option is enabled."?

(The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat system
calls will return the correctly updated atime, but those atime updates
won't get flushed to disk unless the inode needs to be updated for
file system / data consistency reasons, or when the inode is pushed
out of memory, or when the file system is unmounted.)

						- Ted

Re: Documenting MS_LAZYTIME

[Michael Kerrisk (man-pages)]

On 02/20/2015 04:49 PM, Eric Sandeen wrote:
> On 2/20/15 2:50 AM, Michael Kerrisk wrote:
>> Hello Ted,
>>
>> Based on your commit message 0ae45f63d4e, I I wrote the documentation
>> below for MS_LAZYTIME, to go into the mount(2) man page. Could you
>> please check it over and let me know if it's accurate. In particular,
>> I added pieces marked with "*" below that were not part of the commit
>> message and I'd like confirmation that they're accurate.
>>
>> Thanks,
>>
>> Michael
>>
>> [[
>>        MS_LAZYTIME (since Linux 3.20)
>>               Only  update  filetimes (atime, mtime, ctime) on the in-
>>               memory version of the file  inode.   The  on-disk  time‐
>>               stamps are updated only when:
> 
> "filetimes" and "file inode" seems a bit awkward.  How about:
> 
>>        MS_LAZYTIME (since Linux 3.20)
>> 		Reduce on-disk updates of inode timestamps (atime, mtime, ctime)
>> 		by maintaining these changes only in memory, unless:
> 
> (maybe I'm bike-shedding too much, if so, sorry).

Nah it''s the good sort of bikeshedding ;-). "filetimes" was a wordo--I 
meant "timestamps". I've taken your wording mostly.

> 
>>               (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 i-node was
>> *                  written to disk.
> 
> Please don't use "i-node" - simply "inode" is much more common in the manpages
> AFAICT.

Yup, that was a typo. Fixed.

>>               This mount option significantly reduces  writes  to  the
>>               inode  table  for workloads that perform frequent random
>>               writes to preallocated files.
> 
> This seems like an overly specific description of a single workload out
> of many which may benefit, but what do others think?  

Fair enough. I reworded that to note it as an example.

> "inode table" is also fairly extN-specific.

I'll await further input on that point.

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 option significantly reduces  writes  to  the
              inode  table  for  some workloads (e.g., when performing
              frequent random writes to preallocated files).

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

Re: Documenting MS_LAZYTIME

[Robert White]

On 02/20/2015 12:50 AM, Michael Kerrisk wrote:
> *             As at Linux 3.20, this option is supported only on ext4.

"As of Linux 3.20" is more correct.

Re: Documenting MS_LAZYTIME

[Austin S Hemmelgarn]

On 2015-02-20 21:56, Theodore Ts'o wrote:
> On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
>>
>>>                This mount option significantly reduces  writes  to  the
>>>                inode  table  for workloads that perform frequent random
>>>                writes to preallocated files.
>>
>> This seems like an overly specific description of a single workload out
>> of many which may benefit, but what do others think?  "inode table" is also
>> fairly extN-specific.
>
> How about somethign like "This mount significantly reduces writes
> needed to update the inode's timestamps, especially mtime and actime.
> Examples of workloads where this could be a large win include frequent
> random writes to preallocated files, as well as cases where the
> MS_STRICTATIME mount option is enabled."?
>
> (The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat system
> calls will return the correctly updated atime, but those atime updates
> won't get flushed to disk unless the inode needs to be updated for
> file system / data consistency reasons, or when the inode is pushed
> out of memory, or when the file system is unmounted.)
>
If you want to list some specific software, it should help with anything 
that uses sqlite (which notably includes firefox and chrome), as well as 
most RDMS software and systemd-journald.

Re: Documenting MS_LAZYTIME

[Eric Sandeen]

On 2/23/15 6:20 AM, Austin S Hemmelgarn wrote:
> On 2015-02-20 21:56, Theodore Ts'o wrote:
>> On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
>>>
>>>>                This mount option significantly reduces  writes  to  the
>>>>                inode  table  for workloads that perform frequent random
>>>>                writes to preallocated files.
>>>
>>> This seems like an overly specific description of a single workload out
>>> of many which may benefit, but what do others think?  "inode table" is also
>>> fairly extN-specific.
>>
>> How about somethign like "This mount significantly reduces writes
>> needed to update the inode's timestamps, especially mtime and actime.
>> Examples of workloads where this could be a large win include frequent
>> random writes to preallocated files, as well as cases where the
>> MS_STRICTATIME mount option is enabled."?
>>
>> (The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat system
>> calls will return the correctly updated atime, but those atime updates
>> won't get flushed to disk unless the inode needs to be updated for
>> file system / data consistency reasons, or when the inode is pushed
>> out of memory, or when the file system is unmounted.)
>>
> If you want to list some specific software, it should help with
> anything that uses sqlite (which notably includes firefox and
> chrome), as well as most RDMS software and systemd-journald.

I'm really uneasy with starting to list specific workloads and applications
here. It's going to get dated quickly, and will lead to endless cargo-cult
tuning.

I'd strongly prefer to just describe what it does (reduces the number of
certain metadata writes to disk) and leave it at that....

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Documenting MS_LAZYTIME

[Michael Kerrisk (man-pages)]

Ted,

On 02/21/2015 03:56 AM, Theodore Ts'o wrote:
> On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
>>
>>>               This mount option significantly reduces  writes  to  the
>>>               inode  table  for workloads that perform frequent random
>>>               writes to preallocated files.
>>
>> This seems like an overly specific description of a single workload out
>> of many which may benefit, but what do others think?  "inode table" is also
>> fairly extN-specific.
> 
> How about somethign like "This mount significantly reduces writes
> needed to update the inode's timestamps, especially mtime and actime.

What is "actime" in the preceding line? Should it be "ctime"?

> Examples of workloads where this could be a large win include frequent
> random writes to preallocated files, as well as cases where the
> MS_STRICTATIME mount option is enabled."?

I think some version of the following text could also usefully go 
into the page, but...

> (The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat system
> calls will return the correctly updated atime, but those atime updates
> won't get flushed to disk unless the inode needs to be updated for
> file system / data consistency reasons, or when the inode is pushed
> out of memory, or when the file system is unmounted.)

I find the wording of there a little confusing. Is the following 
a correct rewrite:

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

?

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Documenting MS_LAZYTIME

[Michael Kerrisk (man-pages)]

On 02/23/2015 05:24 PM, Eric Sandeen wrote:
> On 2/23/15 6:20 AM, Austin S Hemmelgarn wrote:
>> On 2015-02-20 21:56, Theodore Ts'o wrote:
>>> On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
>>>>
>>>>>                This mount option significantly reduces  writes  to  the
>>>>>                inode  table  for workloads that perform frequent random
>>>>>                writes to preallocated files.
>>>>
>>>> This seems like an overly specific description of a single workload out
>>>> of many which may benefit, but what do others think?  "inode table" is also
>>>> fairly extN-specific.
>>>
>>> How about somethign like "This mount significantly reduces writes
>>> needed to update the inode's timestamps, especially mtime and actime.
>>> Examples of workloads where this could be a large win include frequent
>>> random writes to preallocated files, as well as cases where the
>>> MS_STRICTATIME mount option is enabled."?
>>>
>>> (The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat system
>>> calls will return the correctly updated atime, but those atime updates
>>> won't get flushed to disk unless the inode needs to be updated for
>>> file system / data consistency reasons, or when the inode is pushed
>>> out of memory, or when the file system is unmounted.)
>>>
>> If you want to list some specific software, it should help with
>> anything that uses sqlite (which notably includes firefox and
>> chrome), as well as most RDMS software and systemd-journald.
> 
> I'm really uneasy with starting to list specific workloads and applications
> here. It's going to get dated quickly, and will lead to endless cargo-cult
> tuning.
>
> I'd strongly prefer to just describe what it does (reduces the number of
> certain metadata writes to disk) and leave it at that....

I'm inclined to agree that it's probably not useful to list
specific applications, but I think giving some examples
of workloads, as Ted proposed does help the reader get an idea.
It helps some people (e.g., me) better understand what the
point of the feature is.

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

Re: Documenting MS_LAZYTIME

[Theodore Ts'o]

On Thu, Feb 26, 2015 at 09:49:39AM +0100, Michael Kerrisk (man-pages) wrote:
> > How about somethign like "This mount significantly reduces writes
> > needed to update the inode's timestamps, especially mtime and actime.
> 
> What is "actime" in the preceding line? Should it be "ctime"?

Sorry, no, it should be "atime".

> I find the wording of there a little confusing. Is the following 
> a correct rewrite:
> 
>     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.)

Yes, that's correct.  The only other thing I might add is that in the
case of a crash, the atime (or mtime) fields on disk might be out of
date by at most 24 hours.

						- Ted

Re: Documenting MS_LAZYTIME

[Michael Kerrisk (man-pages)]

On 02/26/2015 02:31 PM, Theodore Ts'o wrote:
> On Thu, Feb 26, 2015 at 09:49:39AM +0100, Michael Kerrisk (man-pages) wrote:
>>> How about somethign like "This mount significantly reduces writes
>>> needed to update the inode's timestamps, especially mtime and actime.
>>
>> What is "actime" in the preceding line? Should it be "ctime"?
> 
> Sorry, no, it should be "atime".

Thanks.

>> I find the wording of there a little confusing. Is the following 
>> a correct rewrite:
>>
>>     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.)
> 
> Yes, that's correct.  The only other thing I might add is that in the
> case of a crash, the atime (or mtime) fields on disk might be out of
> date by at most 24 hours.

So in other words, add a sentence to that last para:

    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.

Right?

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

Re: Documenting MS_LAZYTIME

[Theodore Ts'o]

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?

						- Ted

Re: Documenting MS_LAZYTIME

[Michael Kerrisk (man-pages)]

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Documenting MS_LAZYTIME

[Omar Sandoval]

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"?

>               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

Re: Documenting MS_LAZYTIME

[Michael Kerrisk (man-pages)]

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/

Re: Documenting MS_LAZYTIME

[Theodore Ts'o]

With Omar's suggestions, this looks great.

Thanks!!

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Documenting MS_LAZYTIME

[Darrick J. Wong]

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)

"since Linux 4.0".

--D

>               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/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Documenting MS_LAZYTIME

[Michael Kerrisk (man-pages)]

On 02/27/2015 06:51 PM, Darrick J. Wong 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)
> 
> "since Linux 4.0".

D'oh! Yes, thanks. Fixed.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html