mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Luca Stefani <luca.stefani.ge1@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 1/3] block: Export bio_discard_limit
Date: Mon, 2 Sep 2024 23:57:05 +0200	[thread overview]
Message-ID: <20240902215705.GF26776@twin.jikos.cz> (raw)
In-Reply-To: <20240902205828.943155-2-luca.stefani.ge1@gmail.com>

On Mon, Sep 02, 2024 at 10:56:10PM +0200, Luca Stefani wrote:
> It can be used to calculate the sector size limit of each
> discard call allowing filesystem to implement their own
> chunked discard logic with customized behavior, for example
> cancellation due to signals.

Maybe to add context for block layer people why we want to export this:

The fs trim loops over ranges and sends discard requests, some ranges
can be large so it's all transparently handled by blkdev_issue_discard()
and processed in smaller chunks.

We need to insert checks for cancellation (or suspend) requests into the
the loop. Rather than setting an arbitrary chunk length on the
filesystem level I've suggested to use bio_discard_limit() assuming it
will do optimal number of IO requests. Then we don't have to guess
whether 1G or 10G is the right value, unnecessarily increasing the
number of requests when the device could handle larger ranges.

  reply	other threads:[~2024-09-02 21:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02 20:56 [PATCH v2 0/3] btrfs: Don't block suspend during fstrim Luca Stefani
2024-09-02 20:56 ` [PATCH v2 1/3] block: Export bio_discard_limit Luca Stefani
2024-09-02 21:57   ` David Sterba [this message]
2024-09-03  5:07     ` Christoph Hellwig
2024-09-02 20:56 ` [PATCH v2 2/3] btrfs: Split remaining space to discard in chunks Luca Stefani
2024-09-02 22:31   ` Qu Wenruo
2024-09-02 23:41     ` David Sterba
2024-09-02 20:56 ` [PATCH v2 3/3] btrfs: Don't block system suspend during fstrim Luca Stefani
2024-09-02 22:36   ` Qu Wenruo

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=20240902215705.GF26776@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=axboe@kernel.dk \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.stefani.ge1@gmail.com \
    /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

all inboxes | Powered by JetHome®