From: Theodore Ts'o Subject: Re: Documenting MS_LAZYTIME Date: Thu, 26 Feb 2015 08:31:13 -0500 Message-ID: <20150226133113.GD11217@thunk.org> References: <54E7578E.4090809@redhat.com> <20150221025636.GB7922@thunk.org> <54EEDE23.6080009@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eric Sandeen , Ext4 Developers List , Linux btrfs Developers List , XFS Developers , linux-man@vger.kernel.org, Linux-Fsdevel , Linux API To: "Michael Kerrisk (man-pages)" Return-path: Content-Disposition: inline In-Reply-To: <54EEDE23.6080009@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org 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