From: John Garry <[email protected]>
To: Hannes Reinecke <[email protected]>,
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Cc: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected]
Subject: Re: [Patch v9 07/10] block: Add fops atomic write support
Date: Fri, 21 Jun 2024 13:02:34 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 21/06/2024 07:13, Hannes Reinecke wrote:
> On 6/20/24 14:53, John Garry wrote:
>> Support atomic writes by submitting a single BIO with the REQ_ATOMIC set.
>>
>> It must be ensured that the atomic write adheres to its rules, like
>> naturally aligned offset, so call blkdev_dio_invalid() ->
>> blkdev_atomic_write_valid() [with renaming blkdev_dio_unaligned() to
>> blkdev_dio_invalid()] for this purpose. The BIO submission path currently
>> checks for atomic writes which are too large, so no need to check here.
>>
>> In blkdev_direct_IO(), if the nr_pages exceeds BIO_MAX_VECS, then we
>> cannot
>> produce a single BIO, so error in this case.
>>
>> Finally set FMODE_CAN_ATOMIC_WRITE when the bdev can support atomic
>> writes
>> and the associated file flag is for O_DIRECT.
>>
>> Reviewed-by: Martin K. Petersen <[email protected]>
>> Signed-off-by: John Garry <[email protected]>
>> ---
>> block/fops.c | 20 +++++++++++++++++---
>> 1 file changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/block/fops.c b/block/fops.c
>> index 376265935714..be36c9fbd500 100644
>> --- a/block/fops.c
>> +++ b/block/fops.c
>> @@ -34,9 +34,12 @@ static blk_opf_t dio_bio_write_op(struct kiocb *iocb)
>> return opf;
>> }
>> -static bool blkdev_dio_unaligned(struct block_device *bdev, loff_t pos,
>> - struct iov_iter *iter)
>> +static bool blkdev_dio_invalid(struct block_device *bdev, loff_t pos,
>> + struct iov_iter *iter, bool is_atomic)
>> {
>> + if (is_atomic && !generic_atomic_write_valid(iter, pos))
>> + return true;
>> +
>> return pos & (bdev_logical_block_size(bdev) - 1) ||
>> !bdev_iter_is_aligned(bdev, iter);
>> }
>> @@ -72,6 +75,8 @@ static ssize_t __blkdev_direct_IO_simple(struct
>> kiocb *iocb,
>> bio.bi_iter.bi_sector = pos >> SECTOR_SHIFT;
>> bio.bi_write_hint = file_inode(iocb->ki_filp)->i_write_hint;
>> bio.bi_ioprio = iocb->ki_ioprio;
>> + if (iocb->ki_flags & IOCB_ATOMIC)
>> + bio.bi_opf |= REQ_ATOMIC;
>> ret = bio_iov_iter_get_pages(&bio, iter);
>> if (unlikely(ret))
>> @@ -343,6 +348,9 @@ static ssize_t __blkdev_direct_IO_async(struct
>> kiocb *iocb,
>> task_io_account_write(bio->bi_iter.bi_size);
>> }
>> + if (iocb->ki_flags & IOCB_ATOMIC)
>> + bio->bi_opf |= REQ_ATOMIC;
>> +
>> if (iocb->ki_flags & IOCB_NOWAIT)
>> bio->bi_opf |= REQ_NOWAIT;
>> @@ -359,12 +367,13 @@ static ssize_t __blkdev_direct_IO_async(struct
>> kiocb *iocb,
>> static ssize_t blkdev_direct_IO(struct kiocb *iocb, struct iov_iter
>> *iter)
>> {
>> struct block_device *bdev = I_BDEV(iocb->ki_filp->f_mapping->host);
>> + bool is_atomic = iocb->ki_flags & IOCB_ATOMIC;
>> unsigned int nr_pages;
>> if (!iov_iter_count(iter))
>> return 0;
>> - if (blkdev_dio_unaligned(bdev, iocb->ki_pos, iter))
>> + if (blkdev_dio_invalid(bdev, iocb->ki_pos, iter, is_atomic))
>
> Why not passing in iocb->ki_flags here?
> Or, indeed, the entire iocb?
We could (pass the iocb), but we only need to look up one thing -
ki_pos. We already have is_atomic local. I am just trying to make things
as efficient as possible. If you really think it's better (to pass
iocb), then it can be changed.
Thanks,
John
next prev parent reply other threads:[~2024-06-21 12:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 12:53 [Patch v9 00/10] block atomic writes John Garry
2024-06-20 12:53 ` [Patch v9 01/10] block: Pass blk_queue_get_max_sectors() a request pointer John Garry
2024-06-20 14:12 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 02/10] block: Generalize chunk_sectors support as boundary support John Garry
2024-06-20 14:14 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 03/10] fs: Initial atomic write support John Garry
2024-06-21 5:56 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 04/10] fs: Add initial atomic write support info to statx John Garry
2024-06-21 5:57 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 05/10] block: Add core atomic write support John Garry
2024-06-20 19:34 ` Keith Busch
2024-06-21 6:09 ` Hannes Reinecke
2024-06-21 7:41 ` John Garry
2024-06-20 12:53 ` [Patch v9 06/10] block: Add atomic write support for statx John Garry
2024-06-20 19:46 ` Keith Busch
2024-06-21 6:10 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 07/10] block: Add fops atomic write support John Garry
2024-06-20 19:46 ` Keith Busch
2024-06-21 6:13 ` Hannes Reinecke
2024-06-21 12:02 ` John Garry [this message]
2024-06-21 21:23 ` Darrick J. Wong
2024-06-21 9:41 ` Kanchan Joshi
2024-06-20 12:53 ` [Patch v9 08/10] scsi: sd: Atomic " John Garry
2024-06-21 6:15 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 09/10] scsi: scsi_debug: " John Garry
2024-06-21 6:15 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 10/10] nvme: " John Garry
2024-06-20 20:36 ` Keith Busch
2024-06-21 6:17 ` Hannes Reinecke
2024-06-21 9:40 ` Kanchan Joshi
2024-06-20 21:23 ` [Patch v9 00/10] block atomic writes Jens Axboe
2024-06-21 7:59 ` John Garry
2024-06-21 14:28 ` Jens Axboe
2024-06-21 14:41 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox