On Fri, Jan 22, 2021 at 05:46:43PM +0100, Christoph Hellwig wrote: > If the inode is not pinned by the time fsync is called we don't need the > ilock to protect against concurrent clearing of ili_fsync_fields as the > inode won't need a log flush or clearing of these fields. Not taking > the iolock allows for full concurrency of fsync and thus O_DSYNC > completions with io_uring/aio write submissions. > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > --- > fs/xfs/xfs_file.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c > index 588232c77f11e0..ffe2d7c37e26cd 100644 > --- a/fs/xfs/xfs_file.c > +++ b/fs/xfs/xfs_file.c > @@ -200,7 +200,14 @@ xfs_file_fsync( > else if (mp->m_logdev_targp != mp->m_ddev_targp) > xfs_blkdev_issue_flush(mp->m_ddev_targp); > > - error = xfs_fsync_flush_log(ip, datasync, &log_flushed); > + /* > + * Any inode that has dirty modifications in the log is pinned. The > + * racy check here for a pinned inode while not catch modifications s/while/will/ ? Otherwise looks good: Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx> > + * that happen concurrently to the fsync call, but fsync semantics > + * only require to sync previously completed I/O. > + */ > + if (xfs_ipincount(ip)) > + error = xfs_fsync_flush_log(ip, datasync, &log_flushed); > > /* > * If we only have a single device, and the log force about was > -- > 2.29.2 >
