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

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.

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..

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

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)

English is not my native language, sorry for the mistakesArch amd64, GNOME, Dell Vostro

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

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.

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

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.

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

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!

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

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

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

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')