According to Intel, it is important that blocks not be discarded when creating a Linux filesystem on a solid state drive. The document states that the default behaviour (of mke2fs, in March 2015) is not to discard blocks. However, the current mke2fs man page states that:

discard: Attempt to discard blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When the device advertises that discard also zeroes data (any subsequent read after the discard and before write returns zero), then mark all not-yet-zeroed inode tables as zeroed. This significantly speeds up filesystem initialization. This is set as default.

When I format an SSD manually I can prevent block discarding during formatting by adding -E nodiscard to the mke2fs command line, but since distribution installers are automatic, it isn't possible to do this. Is this something to be concerned about?

2 Answers 2


The linked document seems to serve a specific purpose (Linux kernel NVME driver development and benchmarking) and does not represent generic advice to end users.

It claims that ext4 does not discard at mkfs time...

Core Filesystems:

  • ext4 – the default extended option is not to discard blocks at filesystem make time, retain this, and do not add the “discard” extended option as some information will tell you to do.
  • xfs – with mkfs.xfs, add the –K option so that you do not discard blocks.

...and yet it does. It's the very first thing it does.

# mkfs.ext4 /dev/loop0
mke2fs 1.46.4 (18-Aug-2021)
Discarding device blocks: done
Creating filesystem [...]

So if you don't want to discard all data, you need to actively prevent it, for xfs using mkfs.xfs -K as suggested, for ext4 with mkfs.ext4 -E nodiscard.

# mkfs.ext4 -E nodiscard /dev/loop0
mke2fs 1.46.4 (18-Aug-2021)
Creating filesystem [...]

I'm unaware if the default behavior ever changed. As far as I can tell, it's always been the default. Before -E discard,nodiscard options came around there was also -K to keep data (disable default-on discard) with no counterpart option to enable discard were it disabled by default.

The man page once claimed that nodiscard was the default, but I don't see it reflected in code anywhere in the commit history, so maybe it goes back to a documentation mistake.

mke2fs: Deprecate -K option, introduce discard/nodiscard

( Actually, in this commit, it simultaneously claimed that both discard and nodiscard were the default. )

It would be great if nodiscard were the default and fstrim not possible until a week later. Linux is a bit quick to ditch your data. Format the wrong device and even if you notice your mistake immediately, it's already too late to do any kind of data recovery.


Upfront: not really buying it.

This document is older, and might not be accurate anymore.

Also, it might plain be wrong; there's historically been a lot of miscommunications around that, and people writing guides are not necessarily the same as people contributing to the linux kernel from the same company. The situation is indeed complex – optimization for one SSD might be the worst thing to do for a different one, and the chipset manufacturers have not found a way to communicate the preferences of their controllers.
However, the NVMe discard functionality has been long standardized (intel has been involved – actually, dominant – in that), and this is its intended usag, so I'd be a fair bit surprised if it wasn't "good".

All in all, using discard gives the SSD more info - what it does with that is up to the SSD. So, working worse with more information that you could as well just ignore: that's actually an SSD controller firmware issue, not a driver issue. I bet intel, being very interested in being well-supported in Linux datacenters, has long fixed that issue.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .