Welcome!

The kernel problem with recent updates has been solved. Find the solution here

Important information
-- Required MX 15/16 Repository Changes
-- Information on torrent hosting changes
-- Information on MX15/16 GPG Keys
-- Spectre and Meltdown vulnerabilities

News
-- Introducing our new Website
-- MX Linux on social media: here

Current releases
-- MX-18.3 Point Release release info here
-- Migration Information to MX-18 here
-- antiX-17.4.1 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

TRIM LUKS SSD full-drive encryption

Ruff
Forum Novice
Forum  Novice
Posts: 9
Joined: Wed May 15, 2019 7:32 pm

TRIM LUKS SSD full-drive encryption

#1

Post by Ruff » Wed May 15, 2019 7:41 pm

Searching for "trim luks" gave nothing, so asking here:

I have installed MX 18 on a new little SSD (Patriot Burst 120GB, claims to have TRIM support), choosing the full-drive encryption.

When looking at /var/log/trim.log I see "/boot: 408.4 MiB (428262400 bytes) trimmed". Well, that's good for the boot partition of 512MB, but can I enable it also on the main partition, /dev/sda2, that's mounted as /dev/mapper/rootfs, and how do I do it? Is it something I can't/shouldn't do because it'll be incompatible and make me lose data?

I suppose I won't need to activate it on the small 2GB (encrypted) swap partition, though if that is a recommended course, help with that too, please? Especially since swap doesn't contain a file system as such, but I'd presume the kernel still knows what swap pages are not in use there. Follow-up to that: Since swap is likely to change more often than the 'main filesystem', should that be given extra attention in trimming more often, less often, not at all?

User avatar
JayM
Forum Guide
Forum Guide
Posts: 1803
Joined: Tue Jan 08, 2019 4:47 am

Re: TRIM LUKS SSD full-drive encryption

#2

Post by JayM » Wed May 15, 2019 9:00 pm

Just edit your fstab to add "discard" as an option for the partitions that you want to enable trim for. For example, for swap change

Code: Select all

UUID=(string)   swap swap	defaults	0	0
to

Code: Select all

UUID=(string)   swap	swap	defaults,discard	0	0
where "(string)" is the actual UUID of your swap partition. Then create a cron job that runs "fstrim -v /path/to/mountpoint" for each partition once a week. They don't recommend running it more often as doing so can wear out your SSD faster, reducing its lifespan.

Fstab is run on mounted filesystems, so you would run it on LUKS volumes after they've been unencrypted and mounted. Therefor LUKS doesn't even enter into the picture as far as trim is concerned: once an encrypted drive is decrypted and mounted Linux treats it just like a nonencrypted drive, and so does fstrim.
Please read How To Ask For Help and How to Break Your System.
MX User Manual: hold down ALT and press F1. Further information may be found in the MX Wiki.

User avatar
fehlix
Forum Veteran
Forum Veteran
Posts: 4605
Joined: Wed Apr 11, 2018 5:09 pm

Re: TRIM LUKS SSD full-drive encryption

#3

Post by fehlix » Wed May 15, 2019 9:43 pm

JayM wrote:
Wed May 15, 2019 9:00 pm
Just edit your fstab to add "discard" .... Then create a cron job that runs "fstrim -v /path/to/mountpoint" for each partition once a week.
I'm struggling a bit with this advice as it appears a mixture of automatic trim (discard) and scheduled trim.
Scheduled trims are by default enabled in MX Linux already.
Gigabyte Z77M-D3H, Intel Xeon E3-1240 V2 (Quad core), 32GB RAM,
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB

User avatar
JayM
Forum Guide
Forum Guide
Posts: 1803
Joined: Tue Jan 08, 2019 4:47 am

Re: TRIM LUKS SSD full-drive encryption

#4

Post by JayM » Wed May 15, 2019 10:17 pm

fehlix wrote:
Wed May 15, 2019 9:43 pm
JayM wrote:
Wed May 15, 2019 9:00 pm
Just edit your fstab to add "discard" .... Then create a cron job that runs "fstrim -v /path/to/mountpoint" for each partition once a week.
I'm struggling a bit with this advice as it appears a mixture of automatic trim (discard) and scheduled trim.
Scheduled trims are by default enabled in MX Linux already.
The information I found on a websearch indicated that adding discard to partitions in fstab merely enabled them to be trimmed with fstrim later. If that's incorrect please let us know, as I could also benefit from the correct way of trimming SSD partitions.

I didn't know that MX already scheduled trims. How often does it do them?
Please read How To Ask For Help and How to Break Your System.
MX User Manual: hold down ALT and press F1. Further information may be found in the MX Wiki.

User avatar
Adrian
Forum Veteran
Forum Veteran
Posts: 10066
Joined: Wed Jul 12, 2006 1:42 am

Re: TRIM LUKS SSD full-drive encryption

#5

Post by Adrian » Wed May 15, 2019 10:45 pm

There's a /etc/cron.weekly/fstrim-mx script so weekly. "discard" option in fstab enables continuous trim (whenever the file is deleted -- not recommended) instead of periodic.

User avatar
JayM
Forum Guide
Forum Guide
Posts: 1803
Joined: Tue Jan 08, 2019 4:47 am

Re: TRIM LUKS SSD full-drive encryption

#6

Post by JayM » Wed May 15, 2019 10:52 pm

Adrian wrote:
Wed May 15, 2019 10:45 pm
There's a /etc/cron.weekly/fstrim-mx script so weekly. "discard" option in fstab enables continuous trim (whenever the file is deleted -- not recommended) instead of periodic.
Thank you (and Fehlix) for the correction.
Please read How To Ask For Help and How to Break Your System.
MX User Manual: hold down ALT and press F1. Further information may be found in the MX Wiki.

User avatar
Adrian
Forum Veteran
Forum Veteran
Posts: 10066
Joined: Wed Jul 12, 2006 1:42 am

Re: TRIM LUKS SSD full-drive encryption

#7

Post by Adrian » Wed May 15, 2019 11:17 pm

Also from what I read swap doesn't need discard argument or manual trim, swap is managed by kernel and trim commands are issued automatically.
fstrim in /etc/cron.weekly/fstrim-mx is run with --all option so the command is run on all partitions that support trim.

For encrypted devices I think you need to modify /etc/crypttab and add "allow-discards" see this: https://wiki.archlinux.org/index.php/Dm ... ives_(SSD)

User avatar
AK-47
Forum Regular
Forum Regular
Posts: 266
Joined: Sun Mar 24, 2019 7:04 pm

Re: TRIM LUKS SSD full-drive encryption

#8

Post by AK-47 » Thu May 16, 2019 12:35 am

Be wary of security implications of this kind of setup. TRIM makes it possible to scan for blocks that are being used on your drive. So your data may be encrypted but unused blocks will not be (they'll be read as zeros). For many this is fine, but if you are paranoid or have higher security requirements, it's worth considering this before enabling TRIM on encrypted partitions.
MX Linux 18.3 - Panasonic CF-30 - 3GB RAM - 160GB HDD - Core 2 Duo

User avatar
JayM
Forum Guide
Forum Guide
Posts: 1803
Joined: Tue Jan 08, 2019 4:47 am

Re: TRIM LUKS SSD full-drive encryption

#9

Post by JayM » Thu May 16, 2019 1:08 am

AK-47 wrote:
Thu May 16, 2019 12:35 am
Be wary of security implications of this kind of setup. TRIM makes it possible to scan for blocks that are being used on your drive. So your data may be encrypted but unused blocks will not be (they'll be read as zeros). For many this is fine, but if you are paranoid or have higher security requirements, it's worth considering this before enabling TRIM on encrypted partitions.
...which has the same effect as encrypting a drive without first filling it with random data. Analysis of the drive could reveal the amount of actual, encrypted data there is, which depending on the user's threat model could be dangerous as it could reveal information about what might be on the disk.

From reading the link provided by Adrian, and other sites liked to from that site, it seems that from a security standpoint the only advantage of enabling trim on encrypted partitions is a scenario in which, on a drive without trim enabled, you change your LUKS passphrase because it became compromised and your computer gets stolen before the blocks containing the old passphrase were overwritten. Someone could potentially access those blocks with forensics apps to obtain the old passphrase and use it to decrypt your drive. That could be gotten around by using a tool such as bleachbit to overwrite free space with random data or zeros. So it seems that the slight performance gain from enabling trim on encrypted drives and partitions isn't worth the extra security risks that doing so causes in many cases, but it may be if the threat model that caused a user to use encryption was merely to protect access to personal data by casual, non-technical thieves, in which case it wouldn't matter if the amount of free space was visible as long as the actual files couldn't be accessed.
Please read How To Ask For Help and How to Break Your System.
MX User Manual: hold down ALT and press F1. Further information may be found in the MX Wiki.

Ruff
Forum Novice
Forum  Novice
Posts: 9
Joined: Wed May 15, 2019 7:32 pm

Re: TRIM LUKS SSD full-drive encryption

#10

Post by Ruff » Thu May 16, 2019 12:08 pm

Adrian wrote:
Wed May 15, 2019 11:17 pm
Also from what I read swap doesn't need discard argument or manual trim, swap is managed by kernel and trim commands are issued automatically.
fstrim in /etc/cron.weekly/fstrim-mx is run with --all option so the command is run on all partitions that support trim.

For encrypted devices I think you need to modify /etc/crypttab and add "allow-discards" see this: https://wiki.archlinux.org/index.php/Dm ... ives_(SSD)
Yes, the default install has a weekly cron job for fstrim, but when it's run, only the /boot partition shows up in /var/log/trim.log . Even though a search for 'how to use trim with linux' says that if you do "lsblk --discard", any device with a non-zero DISC-GRAN and DISC-MAX should be TRIM-able. Here's my output:

NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 2G 0
|-sda1 0 512B 2G 0
|-sda2 0 512B 2G 0
| `-rootfs 0 0B 0B 0
`-sda3 0 512B 2G 0
`-swapfs 0 0B 0B 0

So, for some reason, fstrim (run weekly from /etc/cron.weekly/fstrim-mx) only performs it on sda1, the small boot partition. I feel adventurous, and have just back up the drive, so I'll manually run fstrim with /dev/mapper/rootfs as argument.

...

okay, that was quick.

# fstrim /dev/mapper/rootfs
fstrim: /dev/mapper/rootfs: not a directory
# fstrim /
fstrim: /: the discard operation is not supported

So, as I understand it then, fstrim refuses to do the work because - guesswork here - the encryption doesn't say that the filesystem is on top of a SSD that supports trim, and /(dev/sda2 isn't mounted anywhere either, so fstrim can't work on the unencrypted partition. With the end result being that I can choose to either not run fstrim at all, or _perhaps_ remount the filesystem with the discard option (which works); but then again even if that does perform trimming, it increases the wear on the SSD with each file change operation.

(Note also that rootfs and swapfs _do_ appear in the lsblk output, but as non-trimmable.)

This, i take it, boils down an untrimmable filesystem. I can't even unmount it periodically, or mount sda2 read-only in a temp directory just for the sake of running fstrim [never mind potential data mixup] because _all_ of the sda2 partition is encrypted, so it cannot be mounted at all as a 'regular' filesystem. There's simply no filesystem to mount on it, without first unlocking it and setting up a /dev/mapper entry. Hm, maybe I'm unclear in that sentence. What I mean to say is that unlike for example old Ubuntus ecryptfs where the encrypted files reside on an existing filesystem, here it's impossible to see what filesystem is under the encryption - so from an OS point of view, before the partition is unlocked, even the kernel doesn't know which blocks are in use.

I might have over-simplified or over-complicated things there. But I hope you see what I mean.

Post Reply

Return to “Hardware /Configuration”