linux-kernel - Re: [PATCH 00/19] fs: rework and optimize i

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 13 Dec 2017 10:05:33 -0500
From:   "J. Bruce Fields" <bfields@...ldses.org>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        hch@....de, neilb@...e.de, amir73il@...il.com, jack@...e.de,
        viro@...iv.linux.org.uk
Subject: Re: [PATCH 00/19] fs: rework and optimize i_version handling in
 filesystems

This is great, thanks.

On Wed, Dec 13, 2017 at 09:19:58AM -0500, Jeff Layton wrote:
> With this, we reduce inode metadata updates across all 3 filesystems
> down to roughly the frequency of the timestamp granularity, particularly
> when it's not being queried (the vastly common case).
> 
> The pessimal workload here is 1 byte writes, and it helps that
> significantly. Of course, that's not what we'd consider a real-world
> workload.
> 
> A tiobench-example.fio workload also shows some modest performance
> gains, and I've gotten mails from the kernel test robot that show some
> significant performance gains on some microbenchmarks (case-msync-mt in
> the vm-scalability testsuite to be specific), with an earlier version of
> this set.
> 
> With larger writes, the gains with this patchset mostly vaporize,
> but it does not seem to cause performance to regress anywhere, AFAICT.
> 
> I'm happy to run other workloads if anyone can suggest them.
> 
> At this point, the patchset works and does what it's expected to do in
> my own testing. It seems like it's at least a modest performance win
> across all 3 major disk-based filesystems. It may also encourage others
> to implement i_version as well since it reduces the cost.

Do you have an idea what the remaining cost is?

Especially in the ext4 case, are you still able to measure any
difference in performance between the cases where i_version is turned on
and off, after these patches?

> 
> [1]: On ext4 it must be turned on with the i_version mount option,
>      mostly due to fears of incurring this impact, AFAICT.

So xfs and btrfs both have i_version updates on by default at this
point?  (Assuming the filesystem's created with recent enough tools,
etc.)

--b.