[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54EB5456.5030607@redhat.com>
Date: Mon, 23 Feb 2015 10:24:54 -0600
From: Eric Sandeen <sandeen@...hat.com>
To: Austin S Hemmelgarn <ahferroin7@...il.com>,
"Theodore Ts'o" <tytso@....edu>
CC: Michael Kerrisk <mtk.manpages@...il.com>,
Ext4 Developers List <linux-ext4@...r.kernel.org>,
Linux btrfs Developers List <linux-btrfs@...r.kernel.org>,
XFS Developers <xfs@....sgi.com>, linux-man@...r.kernel.org,
Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: Documenting MS_LAZYTIME
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists