Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.boot > #75108

Re: Do no harm: Data loss from new (bookworm2trixie) discard=async default

From Pascal Hambourg <pascal@plouf.fr.eu.org>
Newsgroups linux.debian.maint.boot, linux.debian.kernel
Subject Re: Do no harm: Data loss from new (bookworm2trixie) discard=async default
Date 2025-05-11 15:00 +0200
Message-ID <KLerD-2jVZ-3@gated-at.bofh.it> (permalink)
References <KKWO5-28Qt-1@gated-at.bofh.it>
Organization Plouf !

Cross-posted to 2 groups.

Show all headers | View raw


On 10/05/2025 at 20:07, Nicholas D Steeves wrote:
> 
> An ultra-brief history: many SSDs including various Samsungs, and if I
> remember correctly many drives with old SandForce controllers have
> broken discard=async.

Correct me if I am wrong, but my understanding is that these SSDs have a 
broken *queued TRIM* feature. discard=sync and discard=async are btrfs 
features and both use queued TRIM if supported by the SSD (and not 
blackisted by the kernel) or non-queued TRIM otherwise.

> Linux-6.2 started enabling discard=async by default (at least for
> btrfs),

To be clear for everyone: without an explicit discard mount option, the 
default for btrfs is now to enable discard in asynchronous mode 
(discard=async) instead of disabling discard (nodiscard). Explicit 
"discard" still enables discard in synchronous mode, (discard=sync). 
Explicit "nodiscard" is now needed to disable discard.

> and deductively this appears to necessarily harm many users of
> at least pre2011-to-2014 SSDs.  Does Linux-6.12.x, for trixie, have
> sufficient quirk coverage to make the new default safe, and fall to back
> to discard=sync for affected hardware?  Alternatively, has our kernel
> been patched to maintain bookworm's 6.2.x behaviour of discard=sync?

As I understand it, it is not the asynchronous mode which may cause data 
loss with non-blacklisted broken TRIM but rather the discard option as a 
whole.

> Security conscious users maintain that it presents a security risk when
> a filesystem issues discards to the underlying LUKS layer.  Are we going
> to start doing this by default for trixie, or are we still going to
> block it at the dm-crypt layer?

The Debian installer already enables discard by default on encrypted 
devices since buster. The "discard" option is available for most 
filesystem types which support it (btrfs, ext4, FAT, HFS+, XFS) but is 
not enabled by default. JFS supports it since Linux 3.7 but this is not 
mentioned in mount(8). It is not available for swap.

The Calamares installer may have different defaults. The package 
calamares-settings-debian has a file /etc/calamares/modules/fstab.conf 
which contains:

ssdExtraMountOptions:
     ext4: discard
     jfs: discard
     xfs: discard
     swap: discard
     btrfs: discard,compress=lzo

Also the fstrim systemd service is enabled and triggered once a week by 
default. Is it safer than online discard with broken TRIM ? If yes, can 
anyone explain why ?

Back to linux.debian.maint.boot | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Do no harm: Data loss from new (bookworm2trixie) discard=async default Nicholas D Steeves <sten@debian.org> - 2025-05-10 20:10 +0200
  Re: Do no harm: Data loss from new (bookworm2trixie) discard=async  default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2025-05-11 15:00 +0200

csiph-web