auto-detect and set -o discard?

auto-detect and set -o discard?

[Christoph Anton Mitterer]

Hey.

Right now it seems, btrfs doesn't automatically set -o discard,
depending on whether or no a SSD is detected.

The FAQ entry https://btrfs.wiki.kernel.org/index.php/FAQ#Does_Btrfs_support_TRIM.2Fdiscard.3F
seems to imply that this was done because of several reasons:


- dm-crypt security issues
  => that should be a non-issue, because AFAIU, dm-crypt itself simply
     blocks any TRIM/discard, unless cryptsetup’s --allow-discards is
     specifically set when opening the device

- disputed performance benefits
  => Is this still questioned?
     I don't have any concrete benchmarks, but I mean using TRIM is
     what probably every SSD manufacturer suggests?


Another disadvantage of not auto-detecting this is that - with default
mount options (i.e. no discard) - VMs and the like, wont give back any
space in their storage images.


Cheers,
Chris

Re: auto-detect and set -o discard?

[Chris Murphy]

On Thu, Jul 1, 2021 at 7:30 PM Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
>
> Hey.
>
> Right now it seems, btrfs doesn't automatically set -o discard,
> depending on whether or no a SSD is detected.
>
> The FAQ entry https://btrfs.wiki.kernel.org/index.php/FAQ#Does_Btrfs_support_TRIM.2Fdiscard.3F
> seems to imply that this was done because of several reasons:
>
>
> - dm-crypt security issues
>   => that should be a non-issue, because AFAIU, dm-crypt itself simply
>      blocks any TRIM/discard, unless cryptsetup’s --allow-discards is
>      specifically set when opening the device
>
> - disputed performance benefits
>   => Is this still questioned?
>      I don't have any concrete benchmarks, but I mean using TRIM is
>      what probably every SSD manufacturer suggests?

It varies depending on make/model but quite a lot of them have said
it's not necessary because they properly over provision their drives
and the FTL is able to adequately infer no longer used blocks when the
FTL detects overwrites. So they say.

The reality is that it's going to depend on the workload. Cheap
devices may not be suitably well provisioned, or they may bog down
when many synchronous discards are issued along with ordinary reads
and writes. Most devices for most workloads are adequately managed by
a weekly fstrim.timer which is often enabled by default by distros.

Heavier write and delete workloads might benefit from discard=async
mount option, new since kernel 5.6.


>
>
> Another disadvantage of not auto-detecting this is that - with default
> mount options (i.e. no discard) - VMs and the like, wont give back any
> space in their storage images.

Sparse file VM images increases tracking cost and associated
performance impact. The best performance comes from a preallocated
file and not making it sparse. Or using logical devices like
partitions or LVM logical volumes.

But also, VM's tend to not pass through discards by default either,
similar to dm-crypt. So in any case additional configuration is
needed.



-- 
Chris Murphy