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.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
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
