All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Adam Borowski <kilobyte@angband.pl>
Cc: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
	dsterba@suse.cz, waxhead <waxhead@dirtcellar.net>,
	linux-btrfs@vger.kernel.org
Subject: Re: Why do we need these mount options?
Date: Sat, 16 Jan 2021 20:21:16 +0300	[thread overview]
Message-ID: <af37a93c-65d3-1213-73cf-1463679d815a@gmail.com> (raw)
In-Reply-To: <20210116151933.GA374963@angband.pl>

16.01.2021 18:19, Adam Borowski пишет:
> On Sat, Jan 16, 2021 at 10:39:51AM +0300, Andrei Borzenkov wrote:
>> 15.01.2021 06:54, Zygo Blaxell пишет:
>>> On the other hand, I'm in favor of deprecating the whole discard option
>>> and going with fstrim instead.  discard in its current form tends to
>>> increase write wear rather than decrease it, especially on metadata-heavy
>>> workloads.  discard is roughly equivalent to running fstrim thousands
>>> of times a day, which is clearly bad for many (most?  all?) SSDs.
>>
>> My (probably naive) understanding so far was that trim on SSD marks
>> areas as "unused" which means SSD need to copy less residual data from
>> erase block when reusing it. Assuming TRIM unit is (significantly)
>> smaller than erase block.
>>
>> I would appreciate if you elaborate how trim results in more write on SSD?
> 
> The areas are not only marked as unused, but also zeroed.  To keep the
> zeroing semantic, every discard must be persisted, thus requiring a write
> to the SSD's metadata (not btrfs metadata) area.
> 

There is no requirement that TRIM did it. If device sets RZAT SUPPORTED
bit, it should return zeroes for trimmed range, but there is no need to
physically zero anything - simply return zeroes for areas marked as
unallocated. Discard must be persisted in allocation table, but then
every write must be persisted in allocation table anyway.

Moreover, to actually zero on TRIM either trim request must be issued
for the full erase block or device must perform garbage collection.

Do you have any links that show that discards increase write load on
physical media? I am really curious.

  reply	other threads:[~2021-01-16 17:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14  2:12 Why do we need these mount options? waxhead
2021-01-14 16:37 ` David Sterba
2021-01-15  0:02   ` waxhead
2021-01-15 15:29     ` David Sterba
2021-01-16  1:47       ` waxhead
2021-01-15  3:54   ` Zygo Blaxell
2021-01-15  9:32     ` waxhead
2021-01-16  0:42       ` Zygo Blaxell
2021-01-16  1:57         ` waxhead
2021-01-16  3:51           ` Zygo Blaxell
2021-01-16  7:39     ` Andrei Borzenkov
2021-01-16 15:19       ` Adam Borowski
2021-01-16 17:21         ` Andrei Borzenkov [this message]
2021-01-16 20:01           ` Zygo Blaxell

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=af37a93c-65d3-1213-73cf-1463679d815a@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=dsterba@suse.cz \
    --cc=kilobyte@angband.pl \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=waxhead@dirtcellar.net \
    /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.