linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Eric Sandeen <sandeen@redhat.com>, Theodore Ts'o <tytso@mit.edu>
Cc: linux-man@vger.kernel.org, Linux API <linux-api@vger.kernel.org>,
	XFS Developers <xfs@oss.sgi.com>,
	mtk.manpages@gmail.com,
	Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Linux btrfs Developers List <linux-btrfs@vger.kernel.org>
Subject: Re: Documenting MS_LAZYTIME
Date: Sat, 21 Feb 2015 08:57:05 +0100	[thread overview]
Message-ID: <54E83A51.6000807@gmail.com> (raw)
In-Reply-To: <54E7578E.4090809@redhat.com>

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

  parent reply	other threads:[~2015-02-21  7:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20  8:50 Documenting MS_LAZYTIME Michael Kerrisk
     [not found] ` <CAHO5Pa0k7QkV_6BDjwTVxa7LV9tFyN9nGFFcSvOC6HYO08wfrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-02-20 12:32   ` Andreas Dilger
2015-02-20 13:22     ` Michael Kerrisk (man-pages)
2015-02-20 15:49 ` Eric Sandeen
2015-02-21  2:56   ` Theodore Ts'o
     [not found]     ` <20150221025636.GB7922-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2015-02-23 12:20       ` Austin S Hemmelgarn
     [not found]         ` <54EB1B19.8050808-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-02-23 16:24           ` Eric Sandeen
2015-02-26  8:53             ` Michael Kerrisk (man-pages)
2015-02-26  8:49       ` Michael Kerrisk (man-pages)
2015-02-26 13:31         ` Theodore Ts'o
2015-02-26 13:36           ` Michael Kerrisk (man-pages)
2015-02-27  0:04             ` Theodore Ts'o
     [not found]               ` <20150227000409.GC17174-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2015-02-27  8:01                 ` Michael Kerrisk (man-pages)
     [not found]                   ` <54F02446.2050008-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-02-27  8:08                     ` Omar Sandoval
2015-02-27  8:36                       ` Michael Kerrisk (man-pages)
     [not found]                         ` <54F02C73.5090601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-02-27 14:18                           ` Theodore Ts'o
2015-02-27 17:51                   ` Darrick J. Wong
     [not found]                     ` <20150227175159.GC11031-PTl6brltDGh4DFYR7WNSRA@public.gmane.org>
2015-03-03  7:14                       ` Michael Kerrisk (man-pages)
2015-02-21  7:57   ` Michael Kerrisk (man-pages) [this message]
2015-02-22 18:30 ` Robert White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E83A51.6000807@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).