LUKS + LVM (and TRIM) with new installation process

qinohe · 2013-01-11 11:07:59

I don't use FAT32 file system, I use EXT4.

I think cfr was referring my setup!

Also, I honestly think you are a-okay with mbr partitioning, but only like 98.312% so. The systemctl enable commands are only applicable if you have device-mapper partitions/block devices that have not been assembled after booting. By using the crypt and lvm2 (and mdadm_udev) in your mkinitcpio, the initramfs is assembling these devices. Since you are using LVM2 on top of your LUKS setup, you only have one real partition to decrypt.

There are ongoing discussions about that, on anandtech

concerning your ongoing quest to find out if Trim is working

First I used this test
This one actually didn't work for me, it returned the same date before and after removal!

Then I checked with fstrim, rally I don't know what to think of the results of both tests
maybe remove discard altogether, as I read that would work too,... who is right?.....

$sudo fstrim -v /
/: 21960294400 bytes were trimmed
$sudo fstrim -v /home
/home: 72698007552 bytes were trimmed
$sudo fstrim -v /var 
/var: 19434913792 bytes were trimmed

Now I also used fstrim on /boot/efi, and this what happened;

$sudo fstrim -v /boot/efi
fstrim: /boot/efi: FITRIM ioctl failed: Inappropriate ioctl for device

Read man fstrim and I think I use the tool the right way!
Did look at man ioctl, going above my head..)
edit: as I understand now, it is for manipulating underlying device parameters in special files!
There is one too on using with terminals, but I don't know yet how to use it.

So maybe this means TRIM is not working for a vfat32 partition.
I don't have the skills to test this, but if anyone has a suggestion.. please come forward..

Also , martvefun, did you read this Linux wiki for SSD tunning? on freeswitch, maybe some useful info there!

Sorry if it's a bit messy post,)

Last edited by qinohe (2013-01-11 11:33:53)

martvefun · 2013-01-11 12:36:14

Thank you for the link, I did some tuning they recommend (I will also try to use tmpfs in the future).
They talk about "partition alignment" but as I understand it doesn't concern me (MBR and BIOS).

For fstrim (I forgot the -v, that's why I got no output). I trim some data (115826900992) at first (after creating the file) but after removing the file testfile.txt, doing the same command returns "0 bytes were trimmed". By the way 115826900992 is 107GB which almost everything of my 117GB lvm lv_arch partition. (same for boot, 182MB trimmed out of 228)

Last edited by martvefun (2013-01-11 12:38:48)

qinohe · 2013-01-11 13:22:58

martvefun wrote:

Thank you for the link, I did some tuning they recommend (I will also try to use tmpfs in the future).

I have one made it 8G, I have 16, so I could make it 15, but I think 8 is enough for now! see fstab post,) /tmp lives on /
I use it for Psd (profile sync deamon), so I think I need it because I don't know when I don't create it, if Psd does!

For fstrim (I forgot the -v, that's why I got no output). I trim some data (115826900992) at first (after creating the file) but after removing the file testfile.txt, doing the same command returns "0 bytes were trimmed". By the way 115826900992 is 107GB which almost everything of my 117GB lvm lv_arch partition. (same for boot, 182MB trimmed out of 228)

So if you use

fstrim -v /

result zero bytes were trimmed? I understand correctly?!!
I haven't got a clue, but maybe it has something to do with lvm.

martvefun · 2013-01-11 14:52:37

qinohe wrote:

So if you use
fstrim -v /
result zero bytes were trimmed? I understand correctly?!!
I haven't got a clue, but maybe it has something to do with lvm.

I retested, when I start my computer,

$ sudo fstrim -v /
/: 115374698496 bytes were trimmed

And always zero after, even if I create&remove big files.

Strike0 · 2013-01-11 19:28:59

The reason for the fstrim reporting zero should be that you have the partition mounted with the allow-discards option (test that if you like). The command is meant for trimming manually. It reports what the drive reports. At startup the drive reports "potential trimmable space" first time, as it does not keep an inventory of what's zeroed already. Once that is done, the discards have been done upon deleting already.

Note: this is my interpretation of the manpage and your results. I did not test it. Note also that you should not use both "allow-discards" and fstrim at the same time regularly, as that will naturally increase cell tearing.

cfr · 2013-01-12 00:50:37

martvefun wrote:

They talk about "partition alignment" but as I understand it doesn't concern me (MBR and BIOS).

As I understand it, getting this right is possible with MBR but just easier with GPT. At least. that's what I've read. I don't think BIOS vs. EFI would make a difference, though.

qinohe · 2013-01-12 10:25:40

martvefun wrote:

I retested, when I start my computer,
$ sudo fstrim -v /
/: 115374698496 bytes were trimmed

So, that one is trimmed!

And always zero after, even if I create&remove big files.

I don't know exactly what you mean with this,
what you mean, is first you check it tells you 115374698496 bytes aligned,
and after removing a big file, the same command gives you output zero?
Really, again I have no clue how to interpret this, it's almost if something is keeping track of your trim's and 'knows' there is nothing more to trim ...
But I guess this is way off the truth..

cfr wrote:

martvefun wrote:
They talk about "partition alignment" but as I understand it doesn't concern me (MBR and BIOS).
As I understand it, getting this right is possible with MBR but just easier with GPT. At least. that's what I've read. I don't think BIOS vs. EFI would make a difference, though.

I have a samsung 830 128G, it's aligned 512.
However I never bothered to change anything!, as it would be alright with modern SSD's to go with the default.
But hey, if you have concerns, dive into it, find the proper alignement for your disk... but I think you're good to go!

martvefun · 2013-01-12 11:34:19

qinohe wrote:

I don't know exactly what you mean with this,
what you mean, is first you check it tells you 115374698496 bytes aligned,
and after removing a big file, the same command gives you output zero?
Really, again I have no clue how to interpret this, it's almost if something is keeping track of your trim's and 'knows' there is nothing more to trim ...
But I guess this is way off the truth..

It's exactly that. I was thinking maybe this command was some kind of "magical" tool saying "now trim the disk !"
So after the boot 107GB trimmed. During use, even if I create and removed immediatly some big files to see if the command would trim some more bytes but no, it "trimmed" (even if I guess there was not really 107GB of data trimmed at once but more alignment as you say) zero bytes.

I have started to transfer my files from my backups and realised that the fstrim command "trim" only 57GB now which is +/- the free space left on my disk. Maybe it helps to understand what's happening...

qinohe wrote:

But hey, if you have concerns, dive into it, find the proper alignement for your disk... but I think you're good to go!

Except if somebody is telling me "you did something wrong, you will get terrible performances and your SSD life will decrease" (as mentioned Strike0, not too much fstrim), I will keep my current configuration

(weekend project : write the french wiki page about luks !)
Edit: Here !

Last edited by martvefun (2013-01-13 12:36:59)

qinohe · 2013-01-12 12:15:20

martvefun wrote:

It's exactly that. I was thinking maybe this command was some kind of "magical" tool saying "now trim the disk !"
So after the boot 107GB trimmed. During use, even if I create and removed immediatly some big files to see if the command would trim some more bytes but no, it "trimmed" (even if I guess there was not really 107GB of data trimmed at once but more alignment as you say).

Hmmm.... firmware..!?

I have started to transfer my files from my backups and realised that the fstrim command "trim" only 57GB now which is +/- the free space left on my disk. Maybe it helps to understand what's happening...

Not quite, shouldn't it trim all? If I run fstrim it always shows the same amount of bytes! edit: and it never shows zero here!

cfr wrote:

But hey, if you have concerns, dive into it, find the proper alignement for your disk... but I think you're good to go!

Expect if somebody is telling me "you did something wrong, you will get terrible performances and your SSD life will decrease" (as mentioned Strike0, not too much fstrim), I will keep my current configuration

Change your quote, cfr didn't write that, I did!

Well yes, I think Strike0 is right

And yes, it's a good idea to stay with that config for a while, test it and tweak it for the good')

(weekend project : write the french wiki page about luks !)

Good luck with that, can't help you, my french is really bad')

Last edited by qinohe (2013-01-12 12:21:48)

Arch Linux

#26 2013-01-11 11:07:59

Re: LUKS + LVM (and TRIM) with new installation process

#27 2013-01-11 12:36:14

Re: LUKS + LVM (and TRIM) with new installation process

#28 2013-01-11 13:22:58

Re: LUKS + LVM (and TRIM) with new installation process

#29 2013-01-11 14:52:37

Re: LUKS + LVM (and TRIM) with new installation process

#30 2013-01-11 19:28:59

Re: LUKS + LVM (and TRIM) with new installation process

#31 2013-01-12 00:50:37

Re: LUKS + LVM (and TRIM) with new installation process

#32 2013-01-12 10:25:40

Re: LUKS + LVM (and TRIM) with new installation process

#33 2013-01-12 11:34:19

Re: LUKS + LVM (and TRIM) with new installation process

#34 2013-01-12 12:15:20

Re: LUKS + LVM (and TRIM) with new installation process

Board footer