All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Levy <contact@ericlevy.name>
To: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: "hardware-assisted zeroing"
Date: Tue, 04 Jan 2022 05:50:47 -0500	[thread overview]
Message-ID: <faa7edb08a5cf68e8668546facbb8c60ae5a22e7.camel@ericlevy.name> (raw)
In-Reply-To: <e3fd9851-ccf4-6f04-b376-56c6f7383de7@gmx.com>

On Mon, 2022-01-03 at 19:51 +0800, Qu Wenruo wrote:

> The filesystem (normally) doesn't maintain such info, what a
> filesystem
> really care is the unused/used space.
> 
> For fstrim case, the filesystem will issue such discard comand to
> most
> (if not all) unused space.
> 
> And one can call fstrim multiple times to do the same work again and
> again, the filesystem won't really care.
> (even the operation can be very time consuming)
> 
> The special thing in btrfs is, there is a cache to record which
> blocks
> have been trimmed. (only in memory, thus after unmount, such cache is
> lost, and on next mount will need to be rebuilt)
> 
> This is to reduce the trim workload with recent async-discard
> optimization.

So in the general case (i.e. no session cache), the trim operation
scans all the allocation structures, to process all non-allocated
space?

> > Why is the
> > command not sent instantly, as soon as the space is freed by the
> > file
> > system?
> 
> If you use discard mount option, then most filesystems will send the
> discard command to the underlying device when some space is freed.
> 
> But please keep in mind that, how such discard command gets handled
> is
> hardware/storage stack dependent.
> 
> Some disk firmware may choose to do discard synchronously, which can
> hugely slow down other operations.
> (That's why btrfs has async-discard optimization, and also why fstrim
> is
> preferred, to avoid unexpected slow down).

Yes, but of course as I have used "instantly", I meant, not necessarily
synchronously, but simply near in time.

The trim operation is not avoiding bottlenecks, even if it is non-
blocking, because it operates at the level of the entire file system,
in a single operation. If Btrfs is able to process discard operations
asynchronously, then mounting with the discard option seems preferable,
as it requires no redundant work, adds no serious delay until until the
calls are made, and depends on no activity (not even automatic
activity) from the admin.

I fail to see a reason for preferring trim over discard.


  reply	other threads:[~2022-01-04 10:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-03 11:08 "hardware-assisted zeroing" Eric Levy
2022-01-03 11:17 ` Qu Wenruo
2022-01-03 11:24   ` Eric Levy
2022-01-03 11:51     ` Qu Wenruo
2022-01-04 10:50       ` Eric Levy [this message]
2022-01-04 20:49         ` Zygo Blaxell
2022-01-04 22:37           ` Eric Levy
2022-01-04 22:46             ` Qu Wenruo
2022-01-05  0:38               ` Paul Jones
2022-01-05  0:44                 ` Eric Levy
2022-01-05  1:12                   ` Paul Jones
2022-01-05  1:20                     ` Eric Levy
2022-01-05  1:21                   ` Zygo Blaxell
2022-01-05  1:26                     ` Eric Levy
2022-01-05  1:33                       ` Zygo Blaxell
2022-01-05  1:37                         ` Eric Levy
2022-01-05  2:20                           ` Zygo Blaxell
2022-01-05  1:32             ` Zygo Blaxell
2022-01-04 22:37         ` Qu Wenruo
2022-01-03 11:46 ` David Disseldorp
2022-01-03 11:57   ` 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=faa7edb08a5cf68e8668546facbb8c60ae5a22e7.camel@ericlevy.name \
    --to=contact@ericlevy.name \
    --cc=linux-btrfs@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.