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],
Himanshu Madhani <[email protected]>
Subject: Re: [Patch v9 05/10] block: Add core atomic write support
Date: Fri, 21 Jun 2024 08:41:56 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 21/06/2024 07:09, Hannes Reinecke wrote:
> On 6/20/24 14:53, John Garry wrote:
> [ .. ]
>> +/*
>> + * Returns max guaranteed bytes which we can fit in a bio.
>> + *
>> + * We request that an atomic_write is ITER_UBUF iov_iter (so a single
>> vector),
>> + * so we assume that we can fit in at least PAGE_SIZE in a segment,
>> apart from
>> + * the first and last segments.
>> + */
>> +static
>> +unsigned int blk_queue_max_guaranteed_bio(struct queue_limits *lim)
>> +{
>> + unsigned int max_segments = min(BIO_MAX_VECS, lim->max_segments);
>> + unsigned int length;
>> +
>> + length = min(max_segments, 2) * lim->logical_block_size;
>> + if (max_segments > 2)
>> + length += (max_segments - 2) * PAGE_SIZE;
>> +
>> + return length;
>> +}
>> +
> Now you got me confused.
>
> Why is the length of an atomic write two times the logical block size?
It's not just that.
> And even if it does, shouldn't an atomic write be aligned to the logical
> block size, so why would you need to add two additional PAGE_SIZE worth
> of length?
> And even if _that_ would be okay, why PAGE_SIZE? We're trying really
> hard to get away from implicit PAGE_SIZE assumptions when doing I/O ...
>
We need to know what is the maximum size which we can guarantee not to
need to split. And we work on basis of worst case scenario, i.e. least
efficient packing of data into iovec[]. However we require a UBUF iter
and that iter will be aligned to LBS, that would mean that first and
last segment would be at least logical block size and middle segments
would be at least PAGE_SIZE.
Thanks,
John
next prev parent reply other threads:[~2024-06-21 7:43 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 [this message]
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
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] \
[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