[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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 ?


Reply to: