[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2150abab-5c70-424b-ad83-74868f8afc8a@oracle.com>
Date: Thu, 6 Feb 2025 10:43:08 +0000
From: John Garry <john.g.garry@...cle.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: brauner@...nel.org, cem@...nel.org, dchinner@...hat.com, hch@....de,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, ojaswin@...ux.ibm.com,
ritesh.list@...il.com, martin.petersen@...cle.com
Subject: Re: [PATCH RFC 07/10] xfs: Add xfs_file_dio_write_atomic()
On 05/02/2025 19:55, Darrick J. Wong wrote:
> On Tue, Feb 04, 2025 at 12:01:24PM +0000, John Garry wrote:
>> Add xfs_file_dio_write_atomic() for dedicated handling of atomic writes.
>>
>> In case of -EAGAIN being returned from iomap_dio_rw(), reissue the write
>> in CoW-based atomic write mode.
>>
>> In the CoW-based atomic write mode, first unshare blocks so that we don't
>> have a cow fork for the data in the range which we are writing.
>>
>> Signed-off-by: John Garry <john.g.garry@...cle.com>
>> ---
>> fs/xfs/xfs_file.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>>
>> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
>> index fd05b66aea3f..12af5cdc3094 100644
>> --- a/fs/xfs/xfs_file.c
>> +++ b/fs/xfs/xfs_file.c
>> @@ -619,6 +619,55 @@ xfs_file_dio_write_aligned(
>> return ret;
>> }
>>
>> +static noinline ssize_t
>> +xfs_file_dio_write_atomic(
>> + struct xfs_inode *ip,
>> + struct kiocb *iocb,
>> + struct iov_iter *from)
>> +{
>> + unsigned int iolock = XFS_IOLOCK_SHARED;
>> + bool use_cow = false;
>> + unsigned int dio_flags;
>> + ssize_t ret;
>> +
>> +retry:
>> + ret = xfs_ilock_iocb_for_write(iocb, &iolock);
>> + if (ret)
>> + return ret;
>> +
>> + ret = xfs_file_write_checks(iocb, from, &iolock);
>> + if (ret)
>> + goto out_unlock;
>> +
>> + if (use_cow) {
>> + ret = xfs_reflink_unshare(ip, iocb->ki_pos,
>> + iov_iter_count(from));
>
> Nit: continuation lines should be indented two tabs:
>
> ret = xfs_reflink_unshare(ip, iocb->ki_pos,
> iov_iter_count(from));
ok
>
>> + if (ret)
>> + goto out_unlock;
>> + }
>> +
>> + trace_xfs_file_direct_write(iocb, from);
>> + if (use_cow)
>> + dio_flags = IOMAP_DIO_ATOMIC_COW;
>> + else
>> + dio_flags = 0;
>
> I also think you could eliminate use_cow by initializing dio_flags to
> zero at the top, OR'ing in IOMAP_DIO_ATOMIC_COW in the retry clause
> below, and using (dio_flags & IOMAP_DIO_ATOMIC_COW) to determine if you
> should call unshare above.
ok, fine, if you think that it is better
>
> Note: This serializes all the software untorn direct writes. I think
> a more performant solution would allocate the cow staging blocks ondisk,
> attach them to the directio ioend context, and alter ->iomap_begin and
> the ioend remap to use the attached blocks, but that's a lot more
> surgery.
sure, that does sound like it's quite intrusive. But whatever we do I
would like to keep the behaviour that racing reads and atomic writes
mean that a read sees all old or all new data. That is how SCSI and NVMe
behaves, even though it is not an advertised atomic write feature.
Thanks,
John
Powered by blists - more mailing lists