On 02/14/2018 04:16 AM, Dave Chinner wrote:
On Tue, Feb 13, 2018 at 03:14:58PM -0800, Darrick J. Wong wrote:
On Tue, Feb 13, 2018 at 04:18:51PM +1100, Dave Chinner wrote:
On Mon, Feb 12, 2018 at 11:33:44AM +0200, Avi Kivity wrote:
You're now trying to guess how we'd solve the busy extent blocking
problem. i.e. you now appear to be assuming we have a plan to fix
this problem and are going to do it immediately. Nothing could be
further from the truth - I said:
this is now important, and so we now need to revisit the issues we
laid out some 8 years ago and work from there.
That does not mean "we're going to fix this now" - it means we need
to look at the problem again and determine if it's the best solution
to the problem being presented to us. There are other avenues we
still need to explore.
Upstream XFS is a general-purpose solution, which means that the code we
add to it must be suitable for everyone -- that means it has to work for
most everyone and be understandable by everyone who reads the code.
I'd like to try to avoid adding weird hacks.
[....]
In other words, more discussion needed:
Indeed, does your application and/or users even care about
[acm]times on your files being absolutely accurate and crash
resilient? i.e. do you use fsync() or fdatasync() to guarantee the
data is on stable storage?
Because what I'm getting at here is this:
$ man 8 mount
.....
lazytime
Only update times (atime, mtime, ctime) on the
in-memory version of the file inode.
This mount option significantly reduces writes to the
inode table for workloads that perform frequent random
writes to preallocated files.
The on-disk timestamps are updated only when:
- the inode needs to be updated for some change
unrelated to file timestamps
- the application employs fsync(2), syncfs(2), or
sync(2)
- an undeleted inode is evicted from memory
- more than 24 hours have passed since the i-node was
written to disk.
This has been implemented for ext4 and f2fs, but not for XFS.
Implementing this for XFS and then using it for your application
will basically get rid of the blocking that is occurring in
timestamp updates by removing the transaction/locking we are doing
around timestamp updates.
Lazytime would work for us. Our backups are implemented by creating
hardlinks to fully written and fsynced files, so out-of-date mtime
wouldn't harm us too much.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
