fstrim/discard not working?

mouseman · 2014-09-15 20:20:33

I have a Samsung 830 256GB SSD. When I installed Arch, I included noatime,discard on the mount options for / and /home.

However, when I run 'sudo fstrim -v /' and 'sudo fstrim -v /home', I get the following output:

/: 31.6 GiB (33955295232 bytes) trimmed

/home: 83.3 GiB (89416351744 bytes) trimmed

When I repeat the commands immediately after, they return 0 bytes trimmed, but after a reboot they give me these exact same figures as above.

Does this mean discard/trim isn't working?

Last edited by mouseman (2014-09-15 20:21:02)

jeroentbt · 2014-09-15 21:30:03

This was also on my list of things to look in to.
Sorry I can not be of more assistance. Just letting you know you are not alone

graysky · 2014-09-15 21:54:57

Maybe the trim counter is reset on a reboot from the fstrim perspective? No idea but same behavior here.

mouseman · 2014-09-16 11:23:22

So do we know whether discard/fstrim work or not?

If not, what workarounds do we have?

Last edited by mouseman (2014-09-16 11:23:42)

IsSuE · 2014-09-16 11:28:30

I stumbled across the same, and worked around with a daily fstrim cronjob.

Last edited by IsSuE (2014-09-16 11:29:05)

Strike0 · 2014-09-27 16:03:17

mouseman wrote:

When I repeat the commands immediately after, they return 0 bytes trimmed, but after a reboot they give me these exact same figures as above.
Does this mean discard/trim isn't working?

My homebrew reasoning for this is like graysky's: Neither the drive nor the partition table keeps an extra flag per trimmed (zeroed) sector across reboots. Hence, results of what was trimmed already and what is new empty space is gone after a reboot. What is effectively happening when executing fstrim manually (or via cron) is letting the device repeat the check again and again on already zeroed space. I cannot tell you what sort of wear and tear levelling the "repetitive check" induces, but I would not cron it daily for that reason.

Conversely, when you mount with "discard" the trim will be performed only once per emptied block (but for each and every applicable file operation, i.e. also those blocks that may have been filled again between fstrim cron jobs).

If fstrim gives returns non-error, you can expect it (or the discard mount option) works.

If you are doubtful, it is easy to check - for example like this (the check won't work on a LUKS partition, you'd have to offset the sectors for the size of the LUKS header).

jeroentbt · 2014-09-27 20:06:42

Strike0 wrote:

If you are doubtful, it is easy to check - for example like this

Thank you for linking to that test.
For me, the test shows that the discard flag is not working.

Last edited by jeroentbt (2014-09-27 20:07:09)

Bevan · 2014-10-05 12:09:26

jeroentbt wrote:

Thank you for linking to that test.
For me, the test shows that the discard flag is not working.

I don't think the result of that test is reliable. Different drives behave differently on a TRIM command. Some return zeros for the corresponding blocks afterwards, some return some other deterministic data and some do whatever they want: https://en.wikipedia.org/wiki/Trim_(computing)#ATA.

Of course you can double check the behaviour using the fstrim command and see what the drive returns after that.

jeroentbt · 2014-10-05 13:18:48

Bevan wrote:

I don't think the result of that test is reliable.[...]
https://en.wikipedia.org/wiki/Trim_(computing)#ATA.

Interesting. Thank you for that link.

Bevan wrote:

Of course you can double check the behaviour using the fstrim command and see what the drive returns after that.

Ha, of course... Although in my case, the relevant sectors contain exactly the same info when the file is present, deleted (and supposedly trimmed by the discard flag) or manually trimmed.
So I can't attest to anything about this stuff working or not

[root@zechs /]# hdparm --fibmap testfile.txt 

testfile.txt:
 filesystem blocksize 4096, begins at LBA 2097192; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    2370400    2370695        296
[root@zechs /]# hdparm --read-sector 2370400 /dev/sda

/dev/sda:
reading sector 2370400: succeeded
2031 6574 7473 6c20 6e69 0a65 2032 6574
...
0a65 3034 7420 7365 2074 696c 656e 340a
[root@zechs /]# rm testfile.txt 
[root@zechs /]# sync
[root@zechs /]# hdparm --read-sector 2370400 /dev/sda

/dev/sda:
reading sector 2370400: succeeded
2031 6574 7473 6c20 6e69 0a65 2032 6574
...
0a65 3034 7420 7365 2074 696c 656e 340a
[root@zechs /]# fstrim -v /
/: 22.5 GiB (24100700160 bytes) trimmed
[root@zechs /]# hdparm --read-sector 2370400 /dev/sda

/dev/sda:
reading sector 2370400: succeeded
2031 6574 7473 6c20 6e69 0a65 2032 6574
...
0a65 3034 7420 7365 2074 696c 656e 340a
[root@zechs /]#

Strike0 · 2014-10-09 08:50:47

jeroentbt wrote:

Bevan wrote:
I don't think the result of that test is reliable.[...]
https://en.wikipedia.org/wiki/Trim_(computing)#ATA.
Interesting. Thank you for that link.

+1, thanks. And with that knowledge you can also check whether the above test should work for you or not. For example here

 # hdparm -I /dev/sda | grep TRIM
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM

the zeros arrive.

jeroentbt wrote:

Bevan wrote:
Of course you can double check the behaviour using the fstrim command and see what the drive returns after that.
Ha, of course... Although in my case, the relevant sectors contain exactly the same info when the file is present, deleted (and supposedly trimmed by the discard flag) or manually trimmed.
So I can't attest to anything about this stuff working or not

Yes, your drive makes it difficult. But what you could still try is to disable trim in the kernel. If you do that, fstrim will error out. For example here

# fstrim / -v 
fstrim: /: the discard operation is not supported

jeroentbt · 2014-10-09 21:51:19

My salvaged Apple branded SSD (no idea what drive it actually is) says:

 # hdparm -I /dev/sda | grep TRIM
	   *	Data Set Management TRIM supported (limit unknown)

I should probably give up on TRIM untill I get a decent SSD...

Strike0 wrote:

Yes, your drive makes it difficult. But what you could still try is to disable trim in the kernel. If you do that, fstrim will error out. For example here
# fstrim / -v 
fstrim: /: the discard operation is not supported

Could I not just avoid TRIMming by adding nodiscard to fstab and not running fstrim manually or through cron?
Or would disabling TRIM in the kernel actually learn me something?

It sure seems like I'm hogging this thread.
Are you guys seeing that TRIM works on your arch boxes?

Oh, and this post contains some nice links to info on SSDs and how they work: https://bbs.archlinux.org/viewtopic.php … 6#p1307626

Strike0 · 2014-10-10 06:52:42

jeroentbt wrote:

Could I not just avoid TRIMming by adding nodiscard to fstab and not running fstrim manually or through cron?
Or would disabling TRIM in the kernel actually learn me something?

Adding nodiscard is even better. The only thing you would learn from both is that fstrim does error out appropriately. To my understanding what fstrim does is send the trim command for an area to the drive and processing the results the drive reports. The drive bios then figures which blocks need to be trimmed by itself. That's the base of the original question in this thread why the results are lost after a reboot. If the drive does not actually touch the blocks' contents (e.g. zero them), the only thing you can do is confirm the command gets send and believe :-) That's what Bevan meant with double-checking the fstrim command.
All that said I would assume most drives of the last years do it appropriately some way or another anyway. It was once a hot topic because in the first generations of SSD some could not do it at all. It went that far that manufacturers produced updated bios' with trim in order not to hurt sales.

Arch Linux

#1 2014-09-15 20:20:33

fstrim/discard not working?

#2 2014-09-15 21:30:03

Re: fstrim/discard not working?

#3 2014-09-15 21:54:57

Re: fstrim/discard not working?

#4 2014-09-16 11:23:22

Re: fstrim/discard not working?

#5 2014-09-16 11:28:30

Re: fstrim/discard not working?

#6 2014-09-27 16:03:17

Re: fstrim/discard not working?

#7 2014-09-27 20:06:42

Re: fstrim/discard not working?

#8 2014-10-05 12:09:26

Re: fstrim/discard not working?

#9 2014-10-05 13:18:48

Re: fstrim/discard not working?

#10 2014-10-09 08:50:47

Re: fstrim/discard not working?

#11 2014-10-09 21:51:19

Re: fstrim/discard not working?

#12 2014-10-10 06:52:42

Re: fstrim/discard not working?

Board footer