You are not logged in.

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

mouseman
Member
From: Outta nowhere
Registered: 2014-04-04
Posts: 268

fstrim/discard not working?

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)

Offline

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

jeroentbt
Member
From: .be
Registered: 2014-03-29
Posts: 23

Re: fstrim/discard not working?

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 wink

Offline

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

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 9,791
Website

Re: fstrim/discard not working?

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


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

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

mouseman
Member
From: Outta nowhere
Registered: 2014-04-04
Posts: 268

Re: fstrim/discard not working?

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)

Offline

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

IsSuE
Member
From: Upper Austria
Registered: 2006-04-29
Posts: 309

Re: fstrim/discard not working?

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

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

Offline

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

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: fstrim/discard not working?

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

Offline

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

jeroentbt
Member
From: .be
Registered: 2014-03-29
Posts: 23

Re: fstrim/discard not working?

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)

Offline

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

Bevan
Member
Registered: 2009-09-08
Posts: 54

Re: fstrim/discard not working?

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.

Offline

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

jeroentbt
Member
From: .be
Registered: 2014-03-29
Posts: 23

Re: fstrim/discard not working?

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 smile

[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 /]#

Offline

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

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: fstrim/discard not working?

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 smile

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

Offline

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

jeroentbt
Member
From: .be
Registered: 2014-03-29
Posts: 23

Re: fstrim/discard not working?

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

Offline

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

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: fstrim/discard not working?

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.

Offline

Board footer

Powered by FluxBB