All of lore.kernel.org
 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: Wed, 5 Jan 2022 06:46:45 +0800	[thread overview]
Message-ID: <2193547e-d88e-9f53-6777-793b58130afd@gmx.com> (raw)
In-Reply-To: <f264615001da2f24ca418fdaa4b4567b7ff4cb22.camel@ericlevy.name>



On 2022/1/5 06:37, Eric Levy wrote:
> On Tue, 2022-01-04 at 15:49 -0500, Zygo Blaxell wrote:
>
>> Cheap SSD devices wear out faster when issued a lot of discards mixed
>> with small writes, as they lack the specialized hardware and firmware
>> necessary to make discards low-wear operations.  The same flash
>> component
>> is used for both FTL persistence (where discards cause wear) and user
>> data (where writes cause wear), so interleaved short writes and
>> discards
>> cause double the wear compared to the same short writes without
>> discards.
>> The fstrim man page advises not running trim more than once a week to
>> avoid prematurely aging SSDs in this category, while the discard
>> mount
>> option is equivalent to running fstrim 2000-3000 times a day.
>
> It seems much of the discussion relates to the design of physical
> hardware. I would need to learn more about SDD to understand why the
> operations are useful on them, as my thought had been that they would
> be helpful for thin-provisioned logical volumes, but not meaningful on
> physical devices.

I'm not an expert in this area, but IMHO the trim for SSD is to average
the wear, since NAND used in most (if not all) SSD has a write lifespan
limit.

This is a little different from thin-provisioned device.

>
> I wonder whether the same or a different set of concerns from the ones
> raised would be most helpful when considering management of non-
> physical devices.
>

For thin-provisioned device, it's a pretty different story then.

If the thin-provisioned device is just file backed, then trim brings
little to none performance penalty.

As such trim command will just be converted to hole punch of the
filesystem, and even on filesystems like btrfs which has very slow
metadata operations, it's still super fast.

So in that case, you don't really need to bother about the performance
penalty.

But please keep in mind that, even for heavily stacked storage, if the
final physical stack is still on SSD, the trim/discard discussion is
still true, that it's still recommended to use periodic fstrim over
discard mount option.

Thanks,
Qu

  reply	other threads:[~2022-01-04 22:46 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
2022-01-04 20:49         ` Zygo Blaxell
2022-01-04 22:37           ` Eric Levy
2022-01-04 22:46             ` Qu Wenruo [this message]
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=2193547e-d88e-9f53-6777-793b58130afd@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 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.