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

Path	csiph.com!news.mixmin.net!news2.arglkargh.de!news.in-chemnitz.de!3.eu.feeder.erje.net!feeder.erje.net!usenet.goja.nl.eu.org!news.nntp4.net!news.hispagatos.org!srl.newsdeef.eu!news.corradoroberto.it!gothmog.csi.it!bofh.it!news.nic.it!robomod
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	Sun, 11 May 2025 15:00:01 +0200
Message-ID	<KLerD-2jVZ-3@gated-at.bofh.it> (permalink)
References	<KKWO5-28Qt-1@gated-at.bofh.it>
X-Mailbox-Line	From debian-boot-request@lists.debian.org Sun May 11 12:55:53 2025
Old-Return-Path	<pascal@plouf.fr.eu.org>
X-Amavis-Spam-Status	No, score=-6.501 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, KHOP_HELO_FCRDNS=0.399, LDO_WHITELIST=-5] autolearn=unavailable autolearn_force=no
MIME-Version	1.0
User-Agent	Mozilla Thunderbird
Content-Language	fr
Organization	Plouf !
Content-Type	text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding	7bit
X-Mailing-List	<debian-boot@lists.debian.org> archive/latest/219826
List-ID	<debian-boot.lists.debian.org>
List-URL	<https://lists.debian.org/debian-boot/>
List-Archive	https://lists.debian.org/msgid-search/c225627f-624d-44ef-803c-17e6cb1e02de@plouf.fr.eu.org
Approved	robomod@news.nic.it
Lines	55
Sender	robomod@news.nic.it
X-Original-Date	Sun, 11 May 2025 14:55:33 +0200
X-Original-Message-ID	<c225627f-624d-44ef-803c-17e6cb1e02de@plouf.fr.eu.org>
X-Original-References	<87v7q8ibl5.fsf@navis.mail-host-address-is-not-set>
Xref	csiph.com linux.debian.maint.boot:75108 linux.debian.kernel:87526

Cross-posted to 2 groups.

Show key headers only | 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.kernel | 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