Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Eric Levy <contact@ericlevy.name>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: "hardware-assisted zeroing"
Date: Mon, 3 Jan 2022 19:17:23 +0800	[thread overview]
Message-ID: <b0d434dd-e76d-fdfa-baa2-bb7e00d28b01@gmx.com> (raw)
In-Reply-To: <2c80ca8507181b1e65a67bbd4dca459d24a47da2.camel@ericlevy.name>



On 2022/1/3 19:08, Eric Levy wrote:
> I am operating a Btrfs file system on logical volumes provided through
> an iSCSI target. The software managing the volumes shows that they are
> configured for certain features, which include "hardware-assisted
> zeroing" and "space reclamation". Presumably the meaning of these
> features, at least the former, is that a file system, with support of
> the kernel, may issue a SCSI command indicating that a region of a
> block device would be cleared.

This looks pretty much like ATA TRIM or SCSI UNMAP command.

If they are the same, then btrfs supports it by either fstrim command
(recommended) or discard mount option.

Thanks,
Qu

> For a file system, such an operation has
> no direct value, because the contents of de-allocated space is
> irrelevant, but for a logical volume, it creates an opportunity to free
> space on the underlying file system on the back end.
>
> I have searched the term "hardware-assisted zeroing", without finding
> any useful resources on the application of the term.
>
> Does it describe a feature supported by Btrfs or Linux? Is it possible
> for a LUN manager to "know" that Btrfs has freed space on a volume, in
> a region that had previously been allocated?
>
>

  reply	other threads:[~2022-01-03 11:17 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 [this message]
2022-01-03 11:24   ` Eric Levy
2022-01-03 11:51     ` Qu Wenruo
2022-01-04 10:50       ` Eric Levy
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=b0d434dd-e76d-fdfa-baa2-bb7e00d28b01@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox