Re: Documenting MS_LAZYTIME

[Eric Sandeen <sandeen@redhat.com>]

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).

>               (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.

>               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.

-Eric
 
> *             As at Linux 3.20, this option is supported only on ext4.
> ]]
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html