linux-ext4 - Re: Documenting MS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Feb 2015 09:01:10 +0100
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	Theodore Ts'o <tytso@....edu>
CC:	mtk.manpages@...il.com, Eric Sandeen <sandeen@...hat.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 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
              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.)

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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