during normal operation on any space that’s going to be freed, enabled by mount option discard
on demand via the command fstrim
The fstrim way is more flexible as it allows to apply trim on a specific block range, or can be scheduled to time when the filesystem perfomace drop is not critical.
I would imagine that the “can be scheduled” reference is applicable to fstrim.timer.
Could also be an issue in filesystem level caused by TRIM … i read that it can be troublesome on f2fs p.e. but i also do not remember it more detailed. So as if we use fstrim timer it will try and detect if it will work, it should indeed not cause trouble.
And simply enable the timer can be done in systemd module:
By default, F2FS is mounted using a hybrid TRIM mode which behaves as continuous TRIM… As a result of this, users wanting periodic TRIM will need to implicitly set the nodiscard mount option in /etc/fstab or pass it to mount if mounting manually.
discard is synchronous; adding the =async makes it asynchronous, so instead of immediately applying trim as soon as a file is deleted, it will wait until there are larger chunks, plus it has the ability to wait until there is sufficient idle time (if the computer is busy at the time).
From their documentation, it appears that they have no discard options set by default:
discard discard=sync discard=async nodiscard
(default: off, async support since: 5.6)
At least that’s what I assume “default: off” means.
I don’t use btrfs, so I’m just going off of the documentation.
If it is not necessary to immediately discard freed blocks, then the fstrim tool can be used to discard all free blocks in a batch. Scheduling a TRIM during a period of low system activity will prevent latent interference with the performance of other operations.
I might be reading this wrong or a bit misunderstanding the whole idea of the discard option:
discard
discard=sync
discard=async
nodiscard
(default: off, async support since: 5.6)
Enable discarding of freed file blocks. This is useful for SSD devices, thinly provisioned LUNs, or virtual machine images; however, every storage layer must support discard for it to work.
In the synchronous mode (sync or without option value), lack of asynchronous queued TRIM on the backing device TRIM can severely degrade performance, because a synchronous TRIM operation will be attempted instead. Queued TRIM requires newer than SATA revision 3.1 chipsets and devices.
The asynchronous mode (async) gathers extents in larger chunks before sending them to the devices for TRIM. The overhead and performance impact should be negligible compared to the previous mode and it’s supposed to be the preferred mode if needed.
A Btrfs filesystem is able to free unused blocks from an SSD drive supporting the TRIM command. Starting with kernel version 5.6 there is asynchronous discard support, enabled with mount option discard=async. Freed extents are not discarded immediately, but grouped together and trimmed later by a separate worker thread, improving commit latency. https://wiki.archlinux.org/title/btrfs#SSD_TRIM
So discard=async doesn’t seem to have a negative impact on the disks that supports TRIM?
It shouldn’t, but it will still use more delete cycles than using peridic trim on, say, a weekly basis. While it is generally true that modern SSDs have much better endurance than older models, I don’t see why immediate (or near-immediate) discard would give any appreciable value over scheduled periodic trim.
As I quoted above (from the same btrfs wiki page:
If it is not necessary to immediately discard freed blocks, then the fstrim tool can be used to discard all free blocks in a batch. Scheduling a TRIM during a period of low system activity will prevent latent interference with the performance of other operations.
You need to decide how much the security risk vs the extra performance matters to you. Are you trying to protect casual access or stop government operatives? The fact that using trim identifies areas on the disk which do not contain data thus focusing the attack on the areas that do contain data is a pretty specific risk factor.
Thank you. I’ve seen in the Arch Wiki that the security issues seems to concern a non-default method of luks encryption :
The following cases can be distinguished:
The device is encrypted with default dm-crypt LUKS mode:
By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password. See cryptsetup FAQ, section 5.19 What about SSDs, Flash and Hybrid Drives? and Full disk encryption on an ssd.
TRIM can be left disabled if the security issues stated at the top of this section are considered a worse threat than the above bullet.
The device is encrypted with dm-crypt plain mode, or the LUKS header is stored separately:
If plausible deniability is required, TRIM should never be used because of the considerations at the top of this section, or the use of encryption will be given away.
If plausible deniability is not required, TRIM can be used for its performance gains, provided that the security dangers described at the top of this section are not of concern.
I think Trim will work on your encrypted partition with fstrim.timer enabled. The second link you posted is a bit confusing about that because it says that in addition to fstrim.timer tehe is the need to as special parameters to the kernel (via the GRUB bootloader) to enable trim on an encrypted partition. But if i check the state of trim on my partitions i can see that it’s enabled on my encrypted LUKS without added kernel parameters !
But this article is from may 2020 and maybe that kernel possibilities, LUKS and fstrim have made some progress since these date .
nov 01 00:42:08 eos fstrim[4914]: /: 193 GiB (207256236032 bytes) descartado em /dev/sda2
nov 01 00:42:08 eos fstrim[4914]: /boot/efi: 485,1 MiB (508702720 bytes) descartado em /dev/sda1
I just tried this and it only shows me an overview about how and when I enabled the timer. Doesn’t say anything about drives. Is it possible that the service wasn’t running when I started the timer and it will just start running after one week?
