Hello! When I joined Manjaro the 16.06 was the current install media (I choose Manjaro Gnome) and during the graphical installation I opted for encrypting the system.
Now I recently learned that luks by default inhibits trim which is something I actually would want to use on my Samsung 850 EVO SSD.
All the tutorials and guides I found so far (for arch and manjaro) only talk about the /etc/crypttab where I allowed trim for the swap partition, but I fail to figure out how to do that for my / partition as it isn't in crypttab at all. Also setting the rd.luks.options=discard option in Grub does not fix my problem - as it seems that the grub that actually could handle that is not affected by /etc/defaults/grub at all.
For some possible clarification, that is the "1st grub" where the / partition is unlocked:
Where at the red marker the rd.luks.options=discard is actually there but it does not affect the system in the wanted way and I still can not trim my /.
sudo hdparm -I /dev/sda | grep "TRIM"
* Data Set Management TRIM supported (limit 8 blocks)
That shows that the SSD actually supports trim but
sudo fstrim /
fstrim: /: Verwerfungsvorgang wird nicht unterstützt.
thatn this output (in german) means trim is not supported for /
I realy hope you can help me - if any additional information is needed I will happily supply it.
Usually you don't trim swap, because it's hardly used, it's only used these days for suspend, and suspend on Linux is umstritten anyways, especially if you encrypt, which you should do by default.
Now to trim on linux, why do people tell you it doesn't work on LUKS volumes? Not because it doesn't work, because it does (discard doesn't care about the nature of the discarded data, whether it's encrypted or not), if you put the discard parameter in /etc/fstab, it will use trim on the volumes you've added the parameter to. The reason is that discard basically "abandons" data on storage devices, which means that a clever data thief may get some information out of discarded data, like for instance what kind of filesystem you use, what block size is set, etc. So using discard with LUKS is considered bad security practice.
Now in less critical situations, e.g. encryption for regular use, not for capital secrets, you could just enable discard on the root and home volumes in /etc/fstab. I do that myself. I also schedule for ssd's. As long as the ssd's have less than 1 TB of data on them, I think the security risk of enabling discard on partitions inside of an LVM2 with LUKS, is pretty small. The larger the quantity of discarded data however, the greater the sample size to perform data reengineering on.
That is/was just for proof of concept weather /etc/crypttab changes actually worked in any way - as Swap is the only partition in my crypttab I used that.
I know that it should (will) work (when configured right) - I also know now that the devs of luks disable the pass-through by default because you could be leaking some info when soeone analyses the freed spaces .. bla bla .. I want it to work, but I do not know how to get it to work for / .
Sadly not - that is my fstab and it does not work - it neither did for SWAP before I edited the crypttab
Thanks for explaining how trim isn't a realy danger for my - personal use, none top secret - system; But what I am realy realy hoping for is for some idea or push into the right direction on how to actually get it to work, because as you can see I have "enabled" it but still:
So what is different on my system compared to all of the above you posted, only one thing: in crypttab, I just have "discard" as parameter, instead of "allow-discards", and on my system, it just works. I can also sudo fstrim / --verbose, and after a while it just says how many bytes were trimmed. It should just work, what can I say?
To sum it up: Both rd.luks.options=discard and :allow-discards are needed in the kernel commandline to tell luks to allow the trim command to pass down to the drive.
Same goes for the luks,allow-discards in the /etc/fstab for those volumes that are handled by it (in my case swap only)
And last but not least, either add discard in the /etc/fstab or use the system service to do it periodically.
@Zoltan thanks for your time - as to what might be different - maybe your install included the right kernal parameters by default - i don't know =)
Yeah that's one of those things I always reuse, I've just never thought about it, it has always just worked because it made sense. I always use the same environment and kernel parameters, and always use self-compiled kernels with my own kernel config. In the old days, that was the only way to have a reasonable guarantee of a functional bleeding edge system, and I've always kept doing it, guess it still has some advantages lol
Nice you got it sorted out! Not to nit pick, but isn't it generally advised against to use discard as the way to do trim on most SSD's, I've heard, notably the generation before yours, the Samsung 840 evo/pro? It depends on the specific firmware afaik. Sorry for not providing documentation, am on mobile atm.
Indeed there was once a firmware bug with samsung SSDs, which could lead them to brick when trimed; But the linux gods (aka devs) fixed that by blacklisting those models back than. But now they do support it, and with 250GB trimed it was due needed on mine - as I actually thought it -was- triming the whle time I use the system
This topic is already marked as solved and inactive for like 3 years.
Please double check date and last activity of said topic,
before considering posting.
If you have any questions in regards to this subject?
please feel free to start a new topic of your own.
and eventually link to this one for further reference.
If you have any other questions, check our rules and regulations topic.
