All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Bart Van Assche <bvanassche@acm.org>,
	Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH v2 4/4] block/mq-deadline: Prevent zoned write reordering due to I/O prioritization
Date: Wed, 20 Dec 2023 04:53:47 +0100	[thread overview]
Message-ID: <20231220035347.GA30894@lst.de> (raw)
In-Reply-To: <995e1ae3-5d03-453a-8a97-a435bfa3e2c4@kernel.org>

On Wed, Dec 20, 2023 at 10:28:37AM +0900, Damien Le Moal wrote:
> zone, and as I said before, since doing that is nonsensical, getting the IOs to
> fail is fine by me. The user will then be aware that this should not be done.
> 
> f2fs has a problem with that though as that leads to write errors and FS going
> read-only (I guess). btrfs will not have this issue because it uses zone append.
> Need to check dm-zoned as their may be an issue there.
> 
> So what about what I proposed in an earlier email: introduce a bio flag "ignore
> ioprio" that causes bio_set_ioprio() to not set any IO priority and have f2fs
> set that flag for any zone write BIO it issues ? That will solve your f2fs issue
> without messing up good use cases.

How can this even be a problem for f2f2 upsteam where f2fs must only
have a single write per zone outstanding?  I really don't want crap
in the block layer to work around a known broken model (multiple
outstanding WRITE commands per zone) that because it's so known broken
isn't even merged upstream.



  reply	other threads:[~2023-12-20  3:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-18 21:13 [PATCH v2 0/4] Improve I/O priority support in mq-deadline for zoned writes Bart Van Assche
2023-12-18 21:13 ` [PATCH v2 1/4] block/mq-deadline: Rename dd_rq_ioclass() and change its return type Bart Van Assche
2023-12-18 21:13 ` [PATCH v2 2/4] block/mq-deadline: Introduce dd_bio_ioclass() Bart Van Assche
2023-12-18 21:13 ` [PATCH v2 3/4] block/mq-deadline: Introduce deadline_first_rq_past_pos() Bart Van Assche
2023-12-18 21:13 ` [PATCH v2 4/4] block/mq-deadline: Prevent zoned write reordering due to I/O prioritization Bart Van Assche
2023-12-19 12:10   ` Christoph Hellwig
2023-12-19 17:42     ` Bart Van Assche
2023-12-20  0:05       ` Damien Le Moal
2023-12-20  0:48         ` Bart Van Assche
2023-12-20  1:28           ` Damien Le Moal
2023-12-20  3:53             ` Christoph Hellwig [this message]
2023-12-20  4:40               ` Damien Le Moal

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 \
    --in-reply-to=20231220035347.GA30894@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=dlemoal@kernel.org \
    --cc=linux-block@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.