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/
On Feb 20, 2015, at 1:50 AM, Michael Kerrisk <[email protected]> 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
On 20 February 2015 at 13:32, Andreas Dilger <[email protected]> wrote:
> On Feb 20, 2015, at 1:50 AM, Michael Kerrisk <[email protected]> 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/
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.
> ]]
>
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
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
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.
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.
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
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/
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
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
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
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
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/
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
> [email protected]
> http://oss.sgi.com/mailman/listinfo/xfs
Thanks!
--
Omar
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/
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
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/