TRIM not functional on SSD after adding "discard" to FSTAB?

[catlord17]

Hello all.  

I recently had a disk error give me the excuse I needed to buy an SSD.  I bought a 512 gig drive to replace my faulty 500 gig magnetic drive and slapped PCLinuxOS on it... alone.  Then added "discard" to fstab.

I have been running it with wonderment, but noticed that it is slowing down quickly.

Today I ran, as root, a test to see what was going on.

[root@localhost ~]# seq 1 1000 > testfile
[root@localhost ~]# hdparm --fibmap testfile

testfile:
 filesystem blocksize 4096, begins at LBA 63; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0       -          -          -  
[root@localhost ~]# sync
[root@localhost ~]# hdparm --fibmap testfile

testfile:
 filesystem blocksize 4096, begins at LBA 63; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    5046391    5046398          8
[root@localhost ~]# hdparm --read-sector 5046391 /dev/sda

/dev/sda:
reading sector 5046391: succeeded
0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38
0a39 3031 310a 0a31 3231 310a 0a33 3431
310a 0a35 3631 310a 0a37 3831 310a 0a39
3032 320a 0a31 3232 320a 0a33 3432 320a
0a35 3632 320a 0a37 3832 320a 0a39 3033
330a 0a31 3233 330a 0a33 3433 330a 0a35
3633 330a 0a37 3833 330a 0a39 3034 340a
0a31 3234 340a 0a33 3434 340a 0a35 3634
340a 0a37 3834 340a 0a39 3035 350a 0a31
3235 350a 0a33 3435 350a 0a35 3635 350a
0a37 3835 350a 0a39 3036 360a 0a31 3236
360a 0a33 3436 360a 0a35 3636 360a 0a37
3836 360a 0a39 3037 370a 0a31 3237 370a
0a33 3437 370a 0a35 3637 370a 0a37 3837
370a 0a39 3038 380a 0a31 3238 380a 0a33
3438 380a 0a35 3638 380a 0a37 3838 380a
0a39 3039 390a 0a31 3239 390a 0a33 3439
390a 0a35 3639 390a 0a37 3839 390a 0a39
3031 0a30 3031 0a31 3031 0a32 3031 0a33
3031 0a34 3031 0a35 3031 0a36 3031 0a37
3031 0a38 3031 0a39 3131 0a30 3131 0a31
3131 0a32 3131 0a33 3131 0a34 3131 0a35
3131 0a36 3131 0a37 3131 0a38 3131 0a39
3231 0a30 3231 0a31 3231 0a32 3231 0a33
3231 0a34 3231 0a35 3231 0a36 3231 0a37
3231 0a38 3231 0a39 3331 0a30 3331 0a31
3331 0a32 3331 0a33 3331 0a34 3331 0a35
3331 0a36 3331 0a37 3331 0a38 3331 0a39
3431 0a30 3431 0a31 3431 0a32 3431 0a33
3431 0a34 3431 0a35 3431 0a36 3431 0a37
3431 0a38 3431 0a39 3531 0a30 3531 0a31
3531 0a32 3531 0a33 3531 0a34 3531 0a35
[root@localhost ~]# rm testfile
rm: remove regular file `testfile'? y
[root@localhost ~]# sync
[root@localhost ~]# hdparm --read-sector 5046391 /dev/sda

/dev/sda:
reading sector 5046391: succeeded
0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38
0a39 3031 310a 0a31 3231 310a 0a33 3431
310a 0a35 3631 310a 0a37 3831 310a 0a39
3032 320a 0a31 3232 320a 0a33 3432 320a
0a35 3632 320a 0a37 3832 320a 0a39 3033
330a 0a31 3233 330a 0a33 3433 330a 0a35
3633 330a 0a37 3833 330a 0a39 3034 340a
0a31 3234 340a 0a33 3434 340a 0a35 3634
340a 0a37 3834 340a 0a39 3035 350a 0a31
3235 350a 0a33 3435 350a 0a35 3635 350a
0a37 3835 350a 0a39 3036 360a 0a31 3236
360a 0a33 3436 360a 0a35 3636 360a 0a37
3836 360a 0a39 3037 370a 0a31 3237 370a
0a33 3437 370a 0a35 3637 370a 0a37 3837
370a 0a39 3038 380a 0a31 3238 380a 0a33
3438 380a 0a35 3638 380a 0a37 3838 380a
0a39 3039 390a 0a31 3239 390a 0a33 3439
390a 0a35 3639 390a 0a37 3839 390a 0a39
3031 0a30 3031 0a31 3031 0a32 3031 0a33
3031 0a34 3031 0a35 3031 0a36 3031 0a37
3031 0a38 3031 0a39 3131 0a30 3131 0a31
3131 0a32 3131 0a33 3131 0a34 3131 0a35
3131 0a36 3131 0a37 3131 0a38 3131 0a39
3231 0a30 3231 0a31 3231 0a32 3231 0a33
3231 0a34 3231 0a35 3231 0a36 3231 0a37
3231 0a38 3231 0a39 3331 0a30 3331 0a31
3331 0a32 3331 0a33 3331 0a34 3331 0a35
3331 0a36 3331 0a37 3331 0a38 3331 0a39
3431 0a30 3431 0a31 3431 0a32 3431 0a33
3431 0a34 3431 0a35 3431 0a36 3431 0a37
3431 0a38 3431 0a39 3531 0a30 3531 0a31
3531 0a32 3531 0a33 3531 0a34 3531 0a35
[root@localhost ~]#

My fstab looks like this:

[root@localhost ~]# cat /etc/fstab
# Entry for /dev/sda1 :
UUID=49c04286-093b-4341-afa9-001f8517b123 / ext4 noatime,discard 1 1
/dev/mapper/crypt_sda2 /home ext4 noatime,discard 0 0
none /proc proc defaults 0 0
none /dev/pts devpts defaults 0 0
[root@localhost ~]#

I have no swap file, and I am running the last kernel release in the 2.x series from the repo, with BFS and PAE.  I can't run 3.x because it gives no audio on my machine, and my business is creating audio.

What am I doing wrong here?  Why isn't TRIM working?

[pags]

Maybe I'm misreading this...but is your assumption that TRIM is not functional based on the fact that the data is still there?

I don't see were TRIM is required to removed the data immediately, just that it should do it without the file-system's intervention...doing it "too soon" could lead to unnecessary writes (which should be avoided with an SSD)...

Please correct me if I'm going down the wrong path, here...do not want to derail the thread.

[catlord17]

I'm going by this:

http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

And I did issue a sync command for the buffers to be flushed to disk before reading the sectors the second time... which should force a TRIM, right?

[pags]

Did you give the "sync" command enough time to complete?  Flushing disk buffers can sometimes take a few minutes...in the "old" days, the rule of thumb was to run "sync" three times, in a row, to give the command time to flush all the buffers.  Todays computers are much faster, but the SSD still needs some time...

Also, there is this:

Shortcomings

• When software-based disk encryption is in use, using the TRIM command reveals information about which blocks are in use and which are not.^[15]
• TRIM has been defined as a non-queued command by the T13 subcommittee, and consequently incurs massive execution penalty if used carelessly, e.g., if sent after each filesystem delete command. The non-queued nature of the command requires the driver to first finish any operation, issue the TRIM command, then resume normal commands. TRIM can take a lot of time to complete depending on the firmware in the SSD and may even trigger a garbage collection (GC) cycle.^{[citation needed]} This penalty can be minimized in solutions that periodically do a batched TRIM, rather than TRIMming upon every file deletion, by scheduling such batch jobs for times when system utilization is minimal. This TRIM shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued Trim Command.^[16]

from here.

[catlord17]

Interesting.  If this is the case, how do we explain the drastic slowdown from a few days ago when the disk was first installed?  Has TRIM simply not been performed yet?

[pags]

I would think "days" is too long...I was thinking in the order of minutes (possibly tens of minutes, but not more).

I would agree you may have an issue...what file-system are you using?

From the Wikipedia article:

Not all filesystems make use of TRIM. Among the filesystems that can issue TRIM requests automatically are Ext4, Btrfs[22], FAT, GFS2[23] and XFS[24]. However, this is disabled by default due to performance concerns[25], but can be enabled by setting the "discard" mount option. Ext3, NILFS2 and OCFS2 offer ioctls to perform offline trimming. The TRIM specification calls for supporting a list of trim ranges, but as of kernel 3.0 trim is only invoked with a single range that is slower[26]

[Just17]

I know little about this issue but would like to pass on some info that I received about it which hopefully will be helpful.

You are  using an encrypted filesystem on a SSD disk, this implies at least an additional
layer (dm-crypt) between the user filesystem and the SSD disk.

"/dev/mapper/crypt_sda2" mounted on "/home"

1.   You must be using a kernel >3.1 which I think you are ....  where support for TRIM was added to dm-crypt layer.

2.   You need cryptsetup package >= 1.4.0, where support for option "--allow-discards" (TRIM) was added  (pclinuxos currently has version 1.3.1 I believe)

3.   You will need to manually modify the file "/etc/crypttab" to add the option "discard" on the encrypted partition.

Hopefully that will explain your difficulties.

Here is relevant info about Cryptsetup
http://code.google.com/p/cryptsetup/wiki/Cryptsetup140

[pags]

I know little about this issue but would like to pass on some info that I received about it which hopefully will be helpful.

You are  using an encrypted filesystem on a SSD disk, this implies at least an additional
layer (dm-crypt) between the user filesystem and the SSD disk.

"/dev/mapper/crypt_sda2" mounted on "/home"

1.   You must be using a kernel >3.1 which I think you are ....  where support for TRIM was added to dm-crypt layer.

2.   You need cryptsetup package >= 1.4.0, where support for option "--allow-discards" (TRIM) was added  (pclinuxos currently has version 1.3.1 I believe)

3.   You will need to manually modify the file "/etc/crypttab" to add the option "discard" on the encrypted partition.

Hopefully that will explain your difficulties.

Here is relevant info about Cryptsetup
http://code.google.com/p/cryptsetup/wiki/Cryptsetup140

Nice catch!
 

I see it is formatted ext4, as well, so need need to answer my previous question about that...

[catlord17]

I know little about this issue but would like to pass on some info that I received about it which hopefully will be helpful.

You are  using an encrypted filesystem on a SSD disk, this implies at least an additional
layer (dm-crypt) between the user filesystem and the SSD disk.

"/dev/mapper/crypt_sda2" mounted on "/home"

1.   You must be using a kernel >3.1 which I think you are ....  where support for TRIM was added to dm-crypt layer.

2.   You need cryptsetup package >= 1.4.0, where support for option "--allow-discards" (TRIM) was added  (pclinuxos currently has version 1.3.1 I believe)

3.   You will need to manually modify the file "/etc/crypttab" to add the option "discard" on the encrypted partition.

Hopefully that will explain your difficulties.

Here is relevant info about Cryptsetup
http://code.google.com/p/cryptsetup/wiki/Cryptsetup140

Thanks for the info.  This does present a problem, because as I stated at the end of my first post, I can't use Kernel 3.2.x because it apparently doesn't have audio functional for my laptop, and as audio engineering is my job, that kind of kills it.  I guess I am SOL unless a solution for audio is found.

[Just17]

Is there something special about your audio hardware?

[catlord17]

No.  I actually just fixed it... had an audio channel not enabled in KMIX.  Now running in 3.2.18.bfs.pae, but TRIM tests give the same result.

Since I'm now running the new kernel, if I understand correctly, there's nothing to worry about, TRIM will be done with periodic garbage collection?

[Just17]

No.  I actually just fixed it... had an audio channel not enabled in KMIX.  Now running in 3.2.18.bfs.pae, but TRIM tests give the same result.

Since I'm now running the new kernel, if I understand correctly, there's nothing to worry about, TRIM will be done with periodic garbage collection?

Not on the encrypted partition until the package is updated -- see 2. above

[catlord17]

Okay.  Thanks.  I guess that update will be a while.

My crypttab looks like this:

crypt_sda2 UUID=480d95f2-fa62-4bcc-b649-be91458481b4

Where would I put the "discard" option?

My performance on this SSD is now so bad that operations that used to take 7 - 20 minutes are taking 90 minutes.  Unless the problem is actually some sort of configuration problem in my virtual machine, I may just have to buy a magnetic disk and say screw this.  Not what I like to see myself saying after spending $422 on the damned thing.  I do have the virtual drives set to specify SSD... but does that help with Windows XP?

[Just17]

I would imagine the best temporary option would be to use the SSD partition/s unencrypted, in which case all should be good. 

A package request to update  Cryptsetup  would help too.

[catlord17]

I would imagine the best temporary option would be to use the SSD partition/s unencrypted, in which case all should be good. 

A package request to update  Cryptsetup  would help too.

A sound assessment.  Thanks for the help.