From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: Documenting MS_LAZYTIME Date: Fri, 27 Feb 2015 09:36:03 +0100 Message-ID: <54F02C73.5090601@gmail.com> References: <54E7578E.4090809@redhat.com> <20150221025636.GB7922@thunk.org> <54EEDE23.6080009@gmail.com> <20150226133113.GD11217@thunk.org> <54EF2161.90607@gmail.com> <20150227000409.GC17174@thunk.org> <54F02446.2050008@gmail.com> <20150227080800.GA20442@mew> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150227080800.GA20442@mew> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Omar Sandoval Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Theodore Ts'o , Eric Sandeen , linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API , XFS Developers , Linux-Fsdevel , Ext4 Developers List , Linux btrfs Developers List List-Id: linux-api@vger.kernel.org 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-page= s) 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_LAZYTIM= E >>> 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 (atim= e, >> mtime, ctime) by maintaining these changes only in me= m=E2=80=90 >> ory. The on-disk timestamps are updated only when: >> >> (a) the inode needs to be updated for some change unr= e=E2=80=90 >> 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 w= as >> written to disk. >> >> This mount significantly reduces writes needed to upda= te > "This mount option"? Thanks, fixed. >> the inode's timestamps, especially mtime and atim= e. >> However, in the event of a system crash, the atime a= nd >> mtime fields on disk might be out of date by up to = 24 >> hours. >> >> Examples of workloads where this option could be of si= g=E2=80=90 >> nificant benefit include frequent random writes to pr= e=E2=80=90 >> allocated files, as well as cases where the MS_STRICT= A=E2=80=90 >> TIME mount option is also enabled. (The advantage = of >> (MS_STRICTATIME | MS_LAZYTIME) is that stat(2) wi= ll >> return the correctly updated atime, but the ati= me >> updates will be flushed to disk only when (1) the ino= de >> needs to be updated for filesystem / data consisten= cy >> 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=20 to the list above. Thanks, Michael --=20 Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f182.google.com ([74.125.82.182]:41915 "EHLO mail-we0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752093AbbB0IgL (ORCPT ); Fri, 27 Feb 2015 03:36:11 -0500 Message-ID: <54F02C73.5090601@gmail.com> Date: Fri, 27 Feb 2015 09:36:03 +0100 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 To: Omar Sandoval CC: mtk.manpages@gmail.com, "Theodore Ts'o" , Eric Sandeen , linux-man@vger.kernel.org, Linux API , XFS Developers , Linux-Fsdevel , Ext4 Developers List , Linux btrfs Developers List Subject: Re: Documenting MS_LAZYTIME References: <54E7578E.4090809@redhat.com> <20150221025636.GB7922@thunk.org> <54EEDE23.6080009@gmail.com> <20150226133113.GD11217@thunk.org> <54EF2161.90607@gmail.com> <20150227000409.GC17174@thunk.org> <54F02446.2050008@gmail.com> <20150227080800.GA20442@mew> In-Reply-To: <20150227080800.GA20442@mew> Content-Type: text/plain; charset=utf-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 8A6677F50 for ; Fri, 27 Feb 2015 02:36:13 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id EC3A5AC004 for ; Fri, 27 Feb 2015 00:36:12 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by cuda.sgi.com with ESMTP id g0qfUh33vh5NETOO (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 27 Feb 2015 00:36:10 -0800 (PST) Received: by wevk48 with SMTP id k48so18339949wev.3 for ; Fri, 27 Feb 2015 00:36:10 -0800 (PST) Message-ID: <54F02C73.5090601@gmail.com> Date: Fri, 27 Feb 2015 09:36:03 +0100 From: "Michael Kerrisk (man-pages)" MIME-Version: 1.0 Subject: Re: Documenting MS_LAZYTIME References: <54E7578E.4090809@redhat.com> <20150221025636.GB7922@thunk.org> <54EEDE23.6080009@gmail.com> <20150226133113.GD11217@thunk.org> <54EF2161.90607@gmail.com> <20150227000409.GC17174@thunk.org> <54F02446.2050008@gmail.com> <20150227080800.GA20442@mew> In-Reply-To: <20150227080800.GA20442@mew> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Omar Sandoval Cc: Eric Sandeen , Theodore Ts'o , linux-man@vger.kernel.org, Linux API , XFS Developers , mtk.manpages@gmail.com, Linux-Fsdevel , Ext4 Developers List , Linux btrfs Developers List SGVsbG8gT21hciwKCk9uIDAyLzI3LzIwMTUgMDk6MDggQU0sIE9tYXIgU2FuZG92YWwgd3JvdGU6 Cj4gT24gRnJpLCBGZWIgMjcsIDIwMTUgYXQgMDk6MDE6MTBBTSArMDEwMCwgTWljaGFlbCBLZXJy aXNrIChtYW4tcGFnZXMpIHdyb3RlOgo+PiBPbiAwMi8yNy8yMDE1IDAxOjA0IEFNLCBUaGVvZG9y ZSBUcydvIHdyb3RlOgo+Pj4gT24gVGh1LCBGZWIgMjYsIDIwMTUgYXQgMDI6MzY6MzNQTSArMDEw MCwgTWljaGFlbCBLZXJyaXNrIChtYW4tcGFnZXMpIHdyb3RlOgo+Pj4+Cj4+Pj4gICAgIFRoZSBk aXNhZHZhbnRhZ2Ugb2YgTVNfU1RSSUNUQVRJTUUgfCBNU19MQVpZVElNRSBpcyB0aGF0Cj4+Pj4g ICAgIGluIHRoZSBjYXNlIG9mIGEgc3lzdGVtIGNyYXNoLCB0aGUgYXRpbWUgYW5kIG10aW1lIGZp ZWxkcwo+Pj4+ICAgICBvbiBkaXNrIG1pZ2h0IGJlIG91dCBvZiBkYXRlIGJ5IGF0IG1vc3QgMjQg aG91cnMuCj4+Pgo+Pj4gSSdkIGNoYW5nZSB0byAiVGhlIGRpc2FkdmFudGFnZSBvZiBNU19MQVpZ VElNRSBpcyB0aGF0Li4uIiAgYW5kCj4+PiBwZXJoYXBzIG1vdmUgdGhhdCBzbyBpdCdzIGNsZWFy IGl0IGFwcGxpZXMgdG8gYW55IHVzZSBvZiBNU19MQVpZVElNRQo+Pj4gaGFzIHRoaXMgYXMgYSBk b3duc2lkZS4KPj4+Cj4+PiBEb2VzIHRoYXQgbWFrZSBzZW5zZT8KPj4KPj4gVGhhbmtzLCBUZWQu IEdvdCBpdC4gU28sIG5vdyB3ZSBoYXZlOgo+Pgo+PiAgICAgICAgTVNfTEFaWVRJTUUgKHNpbmNl IExpbnV4IDMuMjApCj4+ICAgICAgICAgICAgICAgUmVkdWNlICBvbi1kaXNrICB1cGRhdGVzICBv ZiAgaW5vZGUgIHRpbWVzdGFtcHMgIChhdGltZSwKPj4gICAgICAgICAgICAgICBtdGltZSwgY3Rp bWUpIGJ5IG1haW50YWluaW5nIHRoZXNlIGNoYW5nZXMgb25seSBpbiAgbWVt4oCQCj4+ICAgICAg ICAgICAgICAgb3J5LiAgVGhlIG9uLWRpc2sgdGltZXN0YW1wcyBhcmUgdXBkYXRlZCBvbmx5IHdo ZW46Cj4+Cj4+ICAgICAgICAgICAgICAgKGEpICB0aGUgaW5vZGUgbmVlZHMgdG8gYmUgdXBkYXRl ZCBmb3Igc29tZSBjaGFuZ2UgdW5yZeKAkAo+PiAgICAgICAgICAgICAgICAgICAgbGF0ZWQgdG8g ZmlsZSB0aW1lc3RhbXBzOwo+Pgo+PiAgICAgICAgICAgICAgIChiKSAgdGhlIGFwcGxpY2F0aW9u ICBlbXBsb3lzICBmc3luYygyKSwgIHN5bmNmcygyKSwgIG9yCj4+ICAgICAgICAgICAgICAgICAg ICBzeW5jKDIpOwo+Pgo+PiAgICAgICAgICAgICAgIChjKSAgYW4gdW5kZWxldGVkIGlub2RlIGlz IGV2aWN0ZWQgZnJvbSBtZW1vcnk7IG9yCj4+Cj4+ICAgICAgICAgICAgICAgKGQpICBtb3JlICB0 aGFuIDI0IGhvdXJzIGhhdmUgcGFzc2VkIHNpbmNlIHRoZSBpbm9kZSB3YXMKPj4gICAgICAgICAg ICAgICAgICAgIHdyaXR0ZW4gdG8gZGlzay4KPj4KPj4gICAgICAgICAgICAgICBUaGlzIG1vdW50 IHNpZ25pZmljYW50bHkgcmVkdWNlcyB3cml0ZXMgbmVlZGVkIHRvIHVwZGF0ZQo+ICJUaGlzIG1v dW50IG9wdGlvbiI/CgpUaGFua3MsIGZpeGVkLgoKPj4gICAgICAgICAgICAgICB0aGUgIGlub2Rl J3MgIHRpbWVzdGFtcHMsICBlc3BlY2lhbGx5ICBtdGltZSAgYW5kIGF0aW1lLgo+PiAgICAgICAg ICAgICAgIEhvd2V2ZXIsIGluIHRoZSBldmVudCBvZiBhIHN5c3RlbSBjcmFzaCwgdGhlICBhdGlt ZSAgYW5kCj4+ICAgICAgICAgICAgICAgbXRpbWUgIGZpZWxkcyAgb24gIGRpc2sgbWlnaHQgYmUg b3V0IG9mIGRhdGUgYnkgdXAgdG8gMjQKPj4gICAgICAgICAgICAgICBob3Vycy4KPj4KPj4gICAg ICAgICAgICAgICBFeGFtcGxlcyBvZiB3b3JrbG9hZHMgd2hlcmUgdGhpcyBvcHRpb24gY291bGQg YmUgb2Ygc2ln4oCQCj4+ICAgICAgICAgICAgICAgbmlmaWNhbnQgIGJlbmVmaXQgaW5jbHVkZSBm cmVxdWVudCByYW5kb20gd3JpdGVzIHRvIHByZeKAkAo+PiAgICAgICAgICAgICAgIGFsbG9jYXRl ZCBmaWxlcywgYXMgd2VsbCBhcyBjYXNlcyB3aGVyZSB0aGUgIE1TX1NUUklDVEHigJAKPj4gICAg ICAgICAgICAgICBUSU1FICBtb3VudCAgb3B0aW9uICBpcyBhbHNvIGVuYWJsZWQuICAoVGhlIGFk dmFudGFnZSBvZgo+PiAgICAgICAgICAgICAgIChNU19TVFJJQ1RBVElNRSB8ICBNU19MQVpZVElN RSkgIGlzICB0aGF0ICBzdGF0KDIpICB3aWxsCj4+ICAgICAgICAgICAgICAgcmV0dXJuICB0aGUg IGNvcnJlY3RseSAgdXBkYXRlZCAgYXRpbWUsICBidXQgIHRoZSAgYXRpbWUKPj4gICAgICAgICAg ICAgICB1cGRhdGVzIHdpbGwgYmUgZmx1c2hlZCB0byBkaXNrIG9ubHkgd2hlbiAoMSkgdGhlICBp bm9kZQo+PiAgICAgICAgICAgICAgIG5lZWRzICB0byAgYmUgIHVwZGF0ZWQgZm9yIGZpbGVzeXN0 ZW0gLyBkYXRhIGNvbnNpc3RlbmN5Cj4+ICAgICAgICAgICAgICAgcmVhc29ucyBvciAoMikgdGhl IGlub2RlIGlzIHB1c2hlZCBvdXQgb2YgbWVtb3J5LCBvciAoMykKPj4gICAgICAgICAgICAgICB0 aGUgZmlsZXN5c3RlbSBpcyB1bm1vdW50ZWQuKQo+IElzIGl0IG5lY2Vzc2FyeSB0byByZXBlYXQg dGhlIHJlYXNvbnMgZm9yIGZsdXNoaW5nLCB3aGljaCBhcmUgc3RhdGVkCj4gYWJvdmU/CgpHb29k IHBvaW50LiBJIHJlcGxhY2VkIHRoaXMgcGllY2Ugd2l0aCBqdXN0IGEgZmV3IHdvcmRzIHJlZmVy cmluZyAKdG8gdGhlIGxpc3QgYWJvdmUuCgpUaGFua3MsCgpNaWNoYWVsCgoKLS0gCk1pY2hhZWwg S2VycmlzawpMaW51eCBtYW4tcGFnZXMgbWFpbnRhaW5lcjsgaHR0cDovL3d3dy5rZXJuZWwub3Jn L2RvYy9tYW4tcGFnZXMvCkxpbnV4L1VOSVggU3lzdGVtIFByb2dyYW1taW5nIFRyYWluaW5nOiBo dHRwOi8vbWFuNy5vcmcvdHJhaW5pbmcvCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwp4ZnMgbWFpbGluZyBsaXN0Cnhmc0Bvc3Muc2dpLmNvbQpodHRwOi8v b3NzLnNnaS5jb20vbWFpbG1hbi9saXN0aW5mby94ZnMK