From mboxrd@z Thu Jan 1 00:00:00 1970 From: Omar Sandoval Subject: Re: Documenting MS_LAZYTIME Date: Fri, 27 Feb 2015 00:08:00 -0800 Message-ID: <20150227080800.GA20442@mew> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <54F02446.2050008-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Michael Kerrisk (man-pages)" Cc: 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 On Fri, Feb 27, 2015 at 09:01:10AM +0100, Michael Kerrisk (man-pages) w= rote: > 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. > >=20 > > 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. > >=20 > > Does that make sense? >=20 > Thanks, Ted. Got it. So, now we have: >=20 > MS_LAZYTIME (since Linux 3.20) > Reduce on-disk updates of inode timestamps (atime= , > mtime, ctime) by maintaining these changes only in mem= =E2=80=90 > ory. The on-disk timestamps are updated only when: >=20 > (a) the inode needs to be updated for some change unre= =E2=80=90 > lated to file timestamps; >=20 > (b) the application employs fsync(2), syncfs(2), o= r > sync(2); >=20 > (c) an undeleted inode is evicted from memory; or >=20 > (d) more than 24 hours have passed since the inode wa= s > written to disk. >=20 > This mount significantly reduces writes needed to updat= e "This mount option"? > the inode's timestamps, especially mtime and atime= =2E > However, in the event of a system crash, the atime an= d > mtime fields on disk might be out of date by up to 2= 4 > hours. >=20 > Examples of workloads where this option could be of sig= =E2=80=90 > nificant benefit include frequent random writes to pre= =E2=80=90 > allocated files, as well as cases where the MS_STRICTA= =E2=80=90 > TIME mount option is also enabled. (The advantage o= f > (MS_STRICTATIME | MS_LAZYTIME) is that stat(2) wil= l > return the correctly updated atime, but the atim= e > updates will be flushed to disk only when (1) the inod= e > needs to be updated for filesystem / data consistenc= y > 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? >=20 > Cheers, >=20 > Michael >=20 >=20 > --=20 > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/ >=20 > _______________________________________________ > xfs mailing list > xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org > http://oss.sgi.com/mailman/listinfo/xfs Thanks! --=20 Omar From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f170.google.com ([209.85.192.170]:41930 "EHLO mail-pd0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752008AbbB0IIC (ORCPT ); Fri, 27 Feb 2015 03:08:02 -0500 Received: by pdno5 with SMTP id o5so19379849pdn.8 for ; Fri, 27 Feb 2015 00:08:01 -0800 (PST) Date: Fri, 27 Feb 2015 00:08:00 -0800 From: Omar Sandoval To: "Michael Kerrisk (man-pages)" Cc: "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 Message-ID: <20150227080800.GA20442@mew> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: <54F02446.2050008@gmail.com> Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs Thanks! -- Omar From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 430507F54 for ; Fri, 27 Feb 2015 02:08:08 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 318E430406B for ; Fri, 27 Feb 2015 00:08:04 -0800 (PST) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by cuda.sgi.com with ESMTP id PoTJAJflM0LSfBRl (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 27 Feb 2015 00:08:02 -0800 (PST) Received: by pdjp10 with SMTP id p10so19426131pdj.3 for ; Fri, 27 Feb 2015 00:08:01 -0800 (PST) Date: Fri, 27 Feb 2015 00:08:00 -0800 From: Omar Sandoval Subject: Re: Documenting MS_LAZYTIME Message-ID: <20150227080800.GA20442@mew> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54F02446.2050008@gmail.com> 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: "Michael Kerrisk (man-pages)" Cc: Eric Sandeen , Theodore Ts'o , linux-man@vger.kernel.org, Linux API , XFS Developers , Linux-Fsdevel , Ext4 Developers List , Linux btrfs Developers List T24gRnJpLCBGZWIgMjcsIDIwMTUgYXQgMDk6MDE6MTBBTSArMDEwMCwgTWljaGFlbCBLZXJyaXNr IChtYW4tcGFnZXMpIHdyb3RlOgo+IE9uIDAyLzI3LzIwMTUgMDE6MDQgQU0sIFRoZW9kb3JlIFRz J28gd3JvdGU6Cj4gPiBPbiBUaHUsIEZlYiAyNiwgMjAxNSBhdCAwMjozNjozM1BNICswMTAwLCBN aWNoYWVsIEtlcnJpc2sgKG1hbi1wYWdlcykgd3JvdGU6Cj4gPj4KPiA+PiAgICAgVGhlIGRpc2Fk dmFudGFnZSBvZiBNU19TVFJJQ1RBVElNRSB8IE1TX0xBWllUSU1FIGlzIHRoYXQKPiA+PiAgICAg aW4gdGhlIGNhc2Ugb2YgYSBzeXN0ZW0gY3Jhc2gsIHRoZSBhdGltZSBhbmQgbXRpbWUgZmllbGRz Cj4gPj4gICAgIG9uIGRpc2sgbWlnaHQgYmUgb3V0IG9mIGRhdGUgYnkgYXQgbW9zdCAyNCBob3Vy cy4KPiA+IAo+ID4gSSdkIGNoYW5nZSB0byAiVGhlIGRpc2FkdmFudGFnZSBvZiBNU19MQVpZVElN RSBpcyB0aGF0Li4uIiAgYW5kCj4gPiBwZXJoYXBzIG1vdmUgdGhhdCBzbyBpdCdzIGNsZWFyIGl0 IGFwcGxpZXMgdG8gYW55IHVzZSBvZiBNU19MQVpZVElNRQo+ID4gaGFzIHRoaXMgYXMgYSBkb3du c2lkZS4KPiA+IAo+ID4gRG9lcyB0aGF0IG1ha2Ugc2Vuc2U/Cj4gCj4gVGhhbmtzLCBUZWQuIEdv dCBpdC4gU28sIG5vdyB3ZSBoYXZlOgo+IAo+ICAgICAgICBNU19MQVpZVElNRSAoc2luY2UgTGlu dXggMy4yMCkKPiAgICAgICAgICAgICAgIFJlZHVjZSAgb24tZGlzayAgdXBkYXRlcyAgb2YgIGlu b2RlICB0aW1lc3RhbXBzICAoYXRpbWUsCj4gICAgICAgICAgICAgICBtdGltZSwgY3RpbWUpIGJ5 IG1haW50YWluaW5nIHRoZXNlIGNoYW5nZXMgb25seSBpbiAgbWVt4oCQCj4gICAgICAgICAgICAg ICBvcnkuICBUaGUgb24tZGlzayB0aW1lc3RhbXBzIGFyZSB1cGRhdGVkIG9ubHkgd2hlbjoKPiAK PiAgICAgICAgICAgICAgIChhKSAgdGhlIGlub2RlIG5lZWRzIHRvIGJlIHVwZGF0ZWQgZm9yIHNv bWUgY2hhbmdlIHVucmXigJAKPiAgICAgICAgICAgICAgICAgICAgbGF0ZWQgdG8gZmlsZSB0aW1l c3RhbXBzOwo+IAo+ICAgICAgICAgICAgICAgKGIpICB0aGUgYXBwbGljYXRpb24gIGVtcGxveXMg IGZzeW5jKDIpLCAgc3luY2ZzKDIpLCAgb3IKPiAgICAgICAgICAgICAgICAgICAgc3luYygyKTsK PiAKPiAgICAgICAgICAgICAgIChjKSAgYW4gdW5kZWxldGVkIGlub2RlIGlzIGV2aWN0ZWQgZnJv bSBtZW1vcnk7IG9yCj4gCj4gICAgICAgICAgICAgICAoZCkgIG1vcmUgIHRoYW4gMjQgaG91cnMg aGF2ZSBwYXNzZWQgc2luY2UgdGhlIGlub2RlIHdhcwo+ICAgICAgICAgICAgICAgICAgICB3cml0 dGVuIHRvIGRpc2suCj4gCj4gICAgICAgICAgICAgICBUaGlzIG1vdW50IHNpZ25pZmljYW50bHkg cmVkdWNlcyB3cml0ZXMgbmVlZGVkIHRvIHVwZGF0ZQoiVGhpcyBtb3VudCBvcHRpb24iPwoKPiAg ICAgICAgICAgICAgIHRoZSAgaW5vZGUncyAgdGltZXN0YW1wcywgIGVzcGVjaWFsbHkgIG10aW1l ICBhbmQgYXRpbWUuCj4gICAgICAgICAgICAgICBIb3dldmVyLCBpbiB0aGUgZXZlbnQgb2YgYSBz eXN0ZW0gY3Jhc2gsIHRoZSAgYXRpbWUgIGFuZAo+ICAgICAgICAgICAgICAgbXRpbWUgIGZpZWxk cyAgb24gIGRpc2sgbWlnaHQgYmUgb3V0IG9mIGRhdGUgYnkgdXAgdG8gMjQKPiAgICAgICAgICAg ICAgIGhvdXJzLgo+IAo+ICAgICAgICAgICAgICAgRXhhbXBsZXMgb2Ygd29ya2xvYWRzIHdoZXJl IHRoaXMgb3B0aW9uIGNvdWxkIGJlIG9mIHNpZ+KAkAo+ICAgICAgICAgICAgICAgbmlmaWNhbnQg IGJlbmVmaXQgaW5jbHVkZSBmcmVxdWVudCByYW5kb20gd3JpdGVzIHRvIHByZeKAkAo+ICAgICAg ICAgICAgICAgYWxsb2NhdGVkIGZpbGVzLCBhcyB3ZWxsIGFzIGNhc2VzIHdoZXJlIHRoZSAgTVNf U1RSSUNUQeKAkAo+ICAgICAgICAgICAgICAgVElNRSAgbW91bnQgIG9wdGlvbiAgaXMgYWxzbyBl bmFibGVkLiAgKFRoZSBhZHZhbnRhZ2Ugb2YKPiAgICAgICAgICAgICAgIChNU19TVFJJQ1RBVElN RSB8ICBNU19MQVpZVElNRSkgIGlzICB0aGF0ICBzdGF0KDIpICB3aWxsCj4gICAgICAgICAgICAg ICByZXR1cm4gIHRoZSAgY29ycmVjdGx5ICB1cGRhdGVkICBhdGltZSwgIGJ1dCAgdGhlICBhdGlt ZQo+ICAgICAgICAgICAgICAgdXBkYXRlcyB3aWxsIGJlIGZsdXNoZWQgdG8gZGlzayBvbmx5IHdo ZW4gKDEpIHRoZSAgaW5vZGUKPiAgICAgICAgICAgICAgIG5lZWRzICB0byAgYmUgIHVwZGF0ZWQg Zm9yIGZpbGVzeXN0ZW0gLyBkYXRhIGNvbnNpc3RlbmN5Cj4gICAgICAgICAgICAgICByZWFzb25z IG9yICgyKSB0aGUgaW5vZGUgaXMgcHVzaGVkIG91dCBvZiBtZW1vcnksIG9yICgzKQo+ICAgICAg ICAgICAgICAgdGhlIGZpbGVzeXN0ZW0gaXMgdW5tb3VudGVkLikKSXMgaXQgbmVjZXNzYXJ5IHRv IHJlcGVhdCB0aGUgcmVhc29ucyBmb3IgZmx1c2hpbmcsIHdoaWNoIGFyZSBzdGF0ZWQKYWJvdmU/ Cgo+IAo+IENoZWVycywKPiAKPiBNaWNoYWVsCj4gCj4gCj4gLS0gCj4gTWljaGFlbCBLZXJyaXNr Cj4gTGludXggbWFuLXBhZ2VzIG1haW50YWluZXI7IGh0dHA6Ly93d3cua2VybmVsLm9yZy9kb2Mv bWFuLXBhZ2VzLwo+IExpbnV4L1VOSVggU3lzdGVtIFByb2dyYW1taW5nIFRyYWluaW5nOiBodHRw Oi8vbWFuNy5vcmcvdHJhaW5pbmcvCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiB4ZnMgbWFpbGluZyBsaXN0Cj4geGZzQG9zcy5zZ2kuY29tCj4g aHR0cDovL29zcy5zZ2kuY29tL21haWxtYW4vbGlzdGluZm8veGZzCgpUaGFua3MhCi0tIApPbWFy CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwp4ZnMgbWFp bGluZyBsaXN0Cnhmc0Bvc3Muc2dpLmNvbQpodHRwOi8vb3NzLnNnaS5jb20vbWFpbG1hbi9saXN0 aW5mby94ZnMK