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!
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')
]]>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...
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 !
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..
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!
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.
]]>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.
]]>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.
]]>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.
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)
]]>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,)
]]> --allow-discards
Allow using of discards (TRIM) requests for device. This option
is only relevant for create, luksOpen or loopaesOpen.
I created my partition using "luksFormat" as explained in the wiki page, not "create". If I understand correctly, the option "create" is for "plain" format (they explain here, at 2.2, the difference, not sure it's a god idea to use it, I will need other changes after ?). It seems strange to me that they provide the --allow-discards option for luksOpen but not luksFormat if you need it at the creation to be effective (don't know if I am clear).
I will try with the change in lvm and let you know
Update: when only changing "issue_discards = 1", I got random bytes at <--fibmap> + <fdisk> + <dmsetup> (zeroes for the 3 other combinations) but same data after removing the file.
]]>You need to pass --allow-discards at the luks device *creation*.
Than enable it at boot with cryptdevice=UUID=6dd....b17:lvmname:allow-discards in the kernel line.
Further more I guess it's needed also in /etc/lvm/lvm.conf with the line issue_discards = 1. Redo your initramfs with mkinitcpio after this change.
Please tell me how it goes.
]]>Very surprised about vfat and TRIM. I've read the bit in the manual page now and I'm still not sure I believe it...
]]>Ok so I tried generating 1GB of random data. I got from begin_LBA 9125888 to end_LBA 11452415. So I tried look at the four combinations I see)
- 9125888
- 11711134 (9125888 + 2099200 + 4096 + 481950)
- 11229184 (9125888 + 2099200 + 4096)
- 9607838 (9125888 + 481950)
For the four values, I got random bytes before and after removing the data and doing sync.
What does fstrim ? I tried "fstrim ." in the repository where was the file but I got no output and same results with the four "hdparm --read-sector".
]]>No only zeroes without this value. I tired a few other combination but couldn't find one working. Maybe using other parameters ?
Which parameters you refer to now?
Whats the output of fstrim, is it positive?
If you cant figure the offset out for your case, you can "brute-force" it as well by filling up the partition with random data, selecting a sector in the middle and then delete it again: https://wiki.archlinux.org/index.php/LU … disk_drive
]]>