anchung.chen
Posts: 2
Joined: Tue Mar 08, 2016 1:46 am

RPi4 external USB3 SSD Enable and Check Trim

Thu Jul 11, 2019 1:05 am

I like to put raspbian rootfs on external USB3 SSD of RPI4 for PC like desptop performance, and just found out a way to enable and check the TRIM function for external USB3 SSD (Plextor-EX1 or Samsung portable SSD T3 , etc.)

To enable the Trim , the key point is to add a rule file to /etc/udev/rules.d/ with the specified VID/PID of your USB3 SSD,
1) Use "lsusb" command to list the VID/PID of your USB3 SSD

2) add a rule file to /etc/udev/rules.d/ with following content (use VID/PID value from step #1)
ACTION=="add|change", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"

3) Modify /etc/fstab to have discard attribute, so Kernel will trim the SSD automatically.

4) reboot


To check the TRIM function, on command terminal
1) Install hdparm
sudo apt install hdparm

2) generate a file with random content
sudo dd if=/dev/urandom of=tempfile count=8 bs=512 oflag=direct

3) find the LBA sector number of the file
sudo hdparm --fibmap ./tempfile

4) Read the file by its LBA address (replace LBA value from step #3, and assume SSD on sdb)
sudo hdparm --read-sector LBA /dev/sdb

5) Delete the file and wait 10 second
sudo rm tempfile && sync && sleep 10

6) Read the file by its LBA address again, If the content are all 0000, the Trim is working.
sudo hdparm --read-sector LBA /dev/sdb


See my log file for reference.

Code: Select all

pi@raspberrypi:~ $ sudo apt install hdparm



pi@raspberrypi:/tmp $ lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 3: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 4: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 4: Dev 4, If 2, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M



pi@raspberrypi:/tmp $ lsusb 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 1f28:f001 Cal-Comp 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 006: ID 0781:5575 SanDisk Corp. Cruzer Glide
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub



pi@raspberrypi:/tmp $ sudo vi /etc/udev/rules.d/plextor-EX1-Trim.rules 
pi@raspberrypi:/tmp $ cat /etc/udev/rules.d/plextor-EX1-Trim.rules 
ACTION=="add|change", ATTRS{idVendor}=="1f28", ATTRS{idProduct}=="f001", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"



pi@raspberrypi:/tmp $ sudo vi /etc/fstab
pi@raspberrypi:/tmp $ cat /etc/fstab
proc            /proc           proc    defaults          0       0
PARTUUID=c5a5e651-01  /boot           vfat    defaults          0       2
PARTUUID=921352bd-02  /               ext4    discard,defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
pi@raspberrypi:/tmp $ 



pi@raspberrypi:/mnt $ sudo reboot

***********************************************************************************************


pi@raspberrypi:/mnt $ mount | grep discard
/dev/sdb2 on / type ext4 (rw,noatime,discard,stripe=8191)



pi@raspberrypi:/mnt $ sudo fstrim -v /
/: 0 B (0 bytes) trimmed



pi@raspberrypi:/mnt $ cd /tmp



pi@raspberrypi:/tmp $ sudo dd if=/dev/urandom of=tempfile count=8 bs=512 oflag=direct
8+0 records in
8+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00460324 s, 890 kB/s




pi@raspberrypi:/tmp $ sudo hdparm --fibmap ./tempfile
./tempfile:
 filesystem blocksize 4096, begins at LBA 532480; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0   52828792   52828799          8



pi@raspberrypi:/tmp $ sudo hdparm --read-sector 52828792 /dev/sdb
/dev/sdb:
reading sector 52828792: succeeded
a83c 618d 9df7 3e54 f2d5 b6f1 e8a1 395d
30d7 0f6b 7cf7 6852 554d 38bf c660 738f
0936 fcdf 84d1 974b 38a2 0972 0f31 d85e
11e1 0583 2ffe 2691 1d8e bc5f 52d0 c80d
006d 7126 dd32 d385 cec5 db7d 6aea c684
1b35 9d95 d99e 6431 bf52 42c4 6e1b 87e9
c38e 0f81 6c48 3146 1ec3 167f b81d c817
c93f 2dda 5353 cecb 4c1c 6794 f0d2 25a8
ddd3 ced1 1fa0 954e 04fb 210e 93b4 8e8b
3d88 4962 586b 6b8a 4b02 4660 60d9 e502
c72d 290a 67d7 cdb0 73c2 3f55 1dd4 42f0
9c97 a29a 6134 c1a1 bbad e9f4 fd9c 477d
570a d804 c187 6b7f 3cc9 ab7b 586d 6126
f373 0112 e233 ce7f 3028 8b7b 0edb aef4
3a0e 6d72 d76f 2432 75ee 3278 20f6 d86e
8acf ea91 b91e 6547 e86c c51f 01a9 4dc2
f8f9 07c9 aaeb 2417 4c7e 3f8a cf7d b862
eb39 87eb ec26 4303 fd51 df07 51cd a927
2c7d df14 20a4 ae56 7b02 a4e8 9302 13c1
1333 5771 e4cf d2e6 b5ae 1983 b5ee 71bc
ef5d 9328 8741 a24f 4bd8 fbee 57ce e616
4bc7 4b6a 3fdd 1148 95df e511 f97b 771f
d3aa 9546 b8c8 a632 36f3 f823 0abf 3704
56a9 c30d c732 26d5 688e a7e2 d288 dbd0
58a6 e15f 5ec2 9e0a af63 8323 20c1 13a5
43d2 f725 8330 0421 a8aa cd88 59b8 e13b
2550 c6a1 33a5 1b11 b695 8684 db5c ed9f
f9b0 99ca e09e 71d7 f89f d244 1405 e2f2
6c93 9a7a ff4a 9619 a469 e3a2 5d37 6083
7220 2288 f108 67a0 7819 3137 038f b73f
96d0 21c8 db9d cdf6 cdf3 3043 ab57 4e72
22ba e85f bb7b 4238 add6 8eaa a72e 0021





pi@raspberrypi:/tmp $ sudo rm tempfile && sync && sleep 10






pi@raspberrypi:/tmp $ sudo hdparm --read-sector 52828792 /dev/sdb
/dev/sdb:
reading sector 52828792: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000


jhm
Posts: 1
Joined: Sun Jul 07, 2019 1:26 am

Re: RPi4 external USB3 SSD Enable and Check Trim

Thu Jul 11, 2019 8:35 pm

Thank you very much for the clear instructions! :)

TRIM setup here on my Pi and a Samsung T5 and confirmed as working as per your instructions.

MicroQuettas
Posts: 1
Joined: Fri Jul 19, 2019 1:14 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Fri Jul 19, 2019 1:32 pm

Hello,

Thanks a lot for the clear instructions.

However, on a USB to SATA adapter with a JMicron 578 chip (VID=152d, PID=0578), it will not work (remote IO error) unless you update the chip firmware.
I found a suitable firmware here https://ftp.station-drivers.com/index.p ... 70&lang=fr.

The download tool (Windows) is provided in the zips. First save your original firmware just in case...
Use the version identified as 00.04.00.06 which internally shows as 00.02.00.06.
It will then work and pass the test as described.

Bye
MicroQuettas

Fars
Posts: 97
Joined: Sat Aug 10, 2019 1:18 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Mon Jan 20, 2020 7:33 pm

Thanks for all!
It work fine with my T5 samsung :)

Imightbejerry
Posts: 27
Joined: Fri Dec 13, 2019 5:47 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Fri Feb 07, 2020 9:00 pm

This did not work for me and my Samsung T5.

Code: Select all

ACTION=="change",ATTRS{idVendor}=="04e8",ATTRS{idProduct}=="61f5",SUBSYSTEM=="scsi_disk",ATTR{provisioning_mode}=="unmap"
The problem was that provisioning_mode never got changed from "full" to "unmap"

My work a round was to add the following to /etc/rc.local

Code: Select all

#JHL Additions
echo -n unmap > /sys/block/sda/device/scsi_disk/0:0:0:0/provisioning_mode
This had the desired effect ie

Code: Select all

sudo fstrim -v /
no longer errored out.

If I turn on the discard option if fstab for /dev/sda7 then the authors demonstration of the
kernels continuous trimming gives the same result..

Would it be more efficient to NOT use the discard option to mount but instead turn on
the fstrim.timer service that would invoke the fstrim command once a week?

Any comments?

Imightbejerry
Posts: 27
Joined: Fri Dec 13, 2019 5:47 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Fri Feb 07, 2020 10:00 pm

Ok,

After turning provisioning_mode to unmap and removing the discard option from '/' in fstab I followed the authors demonstration of creating a file and deleting the file.

This time I invoked fstrim on '/' and then observed that the blocks of the file (relative to the device) had been zeroed.

I believe that the discard option was not needed and that running fstrim periodically is sufficient to clean up the SSD.

I enabled the fstrim.timer service and then started the service.. The timer service invokes fstrim on the file systems in /etc/fstab once a week.

Imightbejerry
Posts: 27
Joined: Fri Dec 13, 2019 5:47 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Sat Feb 08, 2020 8:30 pm

Sigh,

I tried adding a clause to my rule file to also try to set thin_provisioning but it had no effect.

So I edited the rule file to delete the added clause and rebooted.

Shazam! this time provisioning_mode was set to 'unmap'. I don''t know what the problem was but I can theorize that possibly I had some kind of invisible character that was screwing up the file...

I ran the current file through the hex dump program and it was one line....I wish I had a copy of the rule file that was not doing the job.

I have commented out my hack in rc.local.

ktb
Posts: 1447
Joined: Fri Dec 26, 2014 7:53 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Sat Feb 08, 2020 8:40 pm

Glad to hear you got it working, Imightbejerry.

It has worked fine for me on my Samsung T5. Not sure what went wrong in your case.

I agree with you that periodic trim (instead of continuous trim) is probably the better way to go.

User avatar
hippie403
Posts: 38
Joined: Fri Aug 09, 2019 12:45 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Sat Feb 08, 2020 11:11 pm

Interesting topic. I had been naively assuming that fstrim would be happening automatically on SSDs. Should fstrim also enabled on SD cards?

User avatar
HawaiianPi
Posts: 5971
Joined: Mon Apr 08, 2013 4:53 am
Location: Aloha, Oregon USA

Re: RPi4 external USB3 SSD Enable and Check Trim

Sun Feb 16, 2020 8:58 pm

hippie403 wrote:
Sat Feb 08, 2020 11:11 pm
Interesting topic. I had been naively assuming that fstrim would be happening automatically on SSDs. Should fstrim also enabled on SD cards?
Depends on the SD card. Not all of them support it, and some just fake it (they pretend to trim, but don't actually do it).

Imightbejerry wrote:
Fri Feb 07, 2020 9:00 pm
Would it be more efficient to NOT use the discard option to mount but instead turn on
the fstrim.timer service that would invoke the fstrim command once a week?
Yea, that's a better way to do it.

Note that there are some errors in the Debian Wiki. You don't need to copy anything for Buster. All you need to do is create the udev rules file for your USB SSD (or adapter) and issue a sudo systemctl start fstrim.timer command. You can confirm it's running by checking the status.
My mind is like a browser. 27 tabs are open, 9 aren't responding,
lots of pop-ups...and where is that annoying music coming from?

Gadgetguy
Posts: 166
Joined: Fri Aug 15, 2014 2:55 am

Re: RPi4 external USB3 SSD Enable and Check Trim

Mon Feb 24, 2020 5:46 pm

In hopes of eliciting a response I will repeat in this thread a question I asked previously on another thread which went unanswered :

Re: STICKY: If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this at:

viewtopic.php?f=28&t=245931&start=75#p1601716

Namely if you have used quirks to disable uas and are therefore using your ssd as a usb mass storage device is it even possible to enable “ trim”, “unmap” or "discard" on your ssd. Are there any possible workarounds or am I wasting my time trying to find one? What are the real world consequences of not having trim; will there be a noticeable or appreciable degradation of performance or lifespan of the ssd over time?

The following post (answer # 11) provides I think some insight into the problem:

Trim and SSD with usb 3.0 enclosure does not work - UASP not supported?

https://askubuntu.com/questions/262154/ ... -supported

Quote “This is a software issue, Linux does not seem to currently support TRIM through USB. The problem is that USB storage devices employ the SCSI command set, whereas the SSD drive implements the ATA command set. The USB enclosure has to provide a translator between these command sets. The operation called TRIM in ATA is called UNMAP in SCSI and DISCARD in the Linux kernel. When Linux receives the command to trim a device, it looks up the correct command to be sent to the device. As USB storage devices look like SCSI disks, Linux tries to use UNMAP or a couple of other possible SCSI commands. In principle, the translator in the USB enclosure could often translate UNMAP requests to the corresponding ATA TRIM, although there are probably tricky cases. In practice, the enclosures don't do this, and they indicate instead that the device does not support UNMAP. However, many enclosures implement a SCSI command to issue ATA commands directly to the device. It is called ATA passthrough. There is a standard command to do this, but some enclosures have a proprietary command instead. In fact, hdparm -I uses ATA passthrough to get information from the device. The same passthrough could be used to issue TRIMs directly to the device, but the Linux driver does not currently do that. It would have to detect that a SCSI disk is actually a SCSI-to-ATA translator that supports ATA passthrough and use the passthrough for DISCARDs instead of the native SCSI commands.”

As noted in my previous post when I run:

hdparm -I /dev/sda | grep TRIM

I do get:

Data Set Management TRIM supported (limit 8 blocks)

which I understand means the ssd but not necessarily the adapter supports trim

Further when I enabled discard in the fstab file and created a rule file
named “01-unmap.rules“ in /etc/udev/rules.d/
I Rebooted and I again tried “sudo fstrim -v / “ which returned:

"FITRIM ioctl failed: Remote I? O error"


And per the following post:

TRIM support on an USB-attached

https://superuser.com/questions/1456893 ... tached-ssd

Again when I add a rule file to /etc/udev/rules.d and add the discard option to fstab then
when I run:

lsblk –discard

I get:

i@raspberrypi:~ $ lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 4G 0
├─sda1 0 512B 4G 0
└─sda2 0 512B 4G 0
mmcblk0 0 4M 21G 0
├─mmcblk0p1 0 4M 21G 0
└─mmcblk0p2 0 4M 21G 0


The non zero values in sda2 as I understand indicates at least the ssd supports trim


but when I run it without the udev rule and fstab without discard enabled I get


pi@raspberrypi:~ $ lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 0B 0B 0
├─sda1 0 0B 0B 0
└─sda2 0 0B 0B 0
mmcblk0 0 4M 21G 0
├─mmcblk0p1 0 4M 21G 0
└─mmcblk0p2 0 4M 21G 0
pi@raspberrypi:~ $

Gadgetguy
Posts: 166
Joined: Fri Aug 15, 2014 2:55 am

Re: RPi4 external USB3 SSD Enable and Check Trim

Mon Feb 24, 2020 8:15 pm

Gadgetguy post_id=1616956 time=1582566384 user_id=117713] wrote
In hopes of eliciting a response I will repeat in this thread a question I asked previously on another thread which went unanswered ..


I see where a similar question has just recently been asked by another poster SunnyJim at:

viewtopic.php?f=28&t=245931&start=75#p1616718

namely:

"Can someone offer information about disabling UAS and SSDs, longevity and "trim"? Should this be a concern? I assumed the SSD firmware would ensure correct write performance."

Nitrax
Posts: 11
Joined: Sun Mar 15, 2020 4:06 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Sun Mar 15, 2020 4:21 pm

hippie403 wrote:
Sat Feb 08, 2020 11:11 pm
Interesting topic. I had been naively assuming that fstrim would be happening automatically on SSDs. Should fstrim also enabled on SD cards?
Finally I found this thread... I think the fstrim.timer should ABSOLUTELY be enabled by default. The lack of TRIM has been a huge problem for me during 1-2 years, causing me to buy several new SD cards thinking they are bad. The issue happened mainly on a Tinkerboard because I ran my influxdb on that one (a huge writer/deleter), but as I realized fstrim wasnt automatically scheduled on any of my distributions, Raspbian, Armbian nor TinkerOS.

Anyway, after a year or so of influxdb usage my SD card had a write speed of about 1-2MB/sec (Sandisk Ultra A1, spec of about 20MB/sec write speed), starting to cause real problems. Nothing i did worked, formatting or zeroing with different tools (propably because most cheap (?) USB SD readers dont support TRIM command). There were also no actual errors, just really really slow speeds.

When I finally managed to find "fstrim" and running that, I'm now back to 18MB/sec write speeds.

pica200
Posts: 219
Joined: Tue Aug 06, 2019 10:27 am

Re: RPi4 external USB3 SSD Enable and Check Trim

Sun Mar 15, 2020 11:15 pm

Regarding weekly fstrim vs. discard:
It depends. For SATA SSDs discard is fine if the SSD supports command queueing (SATA 3.1). If not stuff like deleting lots of files will be noticeably slower and weekly fstrim makes more sense.

For SD cards discard doesn't seem to be noticeably slower so i just enabled it and it's working fine. And even if they don't support it newer SD cards will at least pretend they do. It's part of newer SD card specs if i recall correctly.

And yeah, fstrim/blkdiscard i found are superior to overwriting and reformatting the cards. No extra writes shortening the lifespan and the SD controller knows exactly which flash pages are now free again.

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2439
Joined: Thu Jul 11, 2013 2:37 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Mon Mar 16, 2020 4:52 am

Nitrax wrote:
Sun Mar 15, 2020 4:21 pm
hippie403 wrote:
Sat Feb 08, 2020 11:11 pm
Interesting topic. I had been naively assuming that fstrim would be happening automatically on SSDs. Should fstrim also enabled on SD cards?
Finally I found this thread... I think the fstrim.timer should ABSOLUTELY be enabled by default. The lack of TRIM has been a huge problem for me during 1-2 years, causing me to buy several new SD cards thinking they are bad. The issue happened mainly on a Tinkerboard because I ran my influxdb on that one (a huge writer/deleter), but as I realized fstrim wasnt automatically scheduled on any of my distributions, Raspbian, Armbian nor TinkerOS.

Anyway, after a year or so of influxdb usage my SD card had a write speed of about 1-2MB/sec (Sandisk Ultra A1, spec of about 20MB/sec write speed), starting to cause real problems. Nothing i did worked, formatting or zeroing with different tools (propably because most cheap (?) USB SD readers dont support TRIM command). There were also no actual errors, just really really slow speeds.

When I finally managed to find "fstrim" and running that, I'm now back to 18MB/sec write speeds.
FStrim isn't issuing trim commands to your SD card. It's issuing block erase commands.

Trim informs the flash controller that "this area is considered unimportant and can be reclaimed at a convenient time", whereas erase forces the flash controller to wipe the associated flash cells - using up some of the limited number of lifetime erase cycles.

SD cards with good flash management should recover performance after a full format. Doing long sequential writes forces the FTL to allocate multiple flash pages per write and in theory it should reclaim fragmented pages by doing copy-on-write. If it doesn't, then as you've seen, random performance starts to degrade.

fstrim will issue many erase commands corresponding to unused spaces in the volume block bitmap that have been used previously. No alignment in terms of block number or length is respected, whereas SD cards have preferred erase sizes corresponding to some internal structure (either flash page erase size or a collection of flash pages the card can manage as a single unit). Issuing random erase commands in this way may significantly amplify the numbers of erases actually performed on the underlying NAND flash.

If a card ends up with poor performance after use, and is not recovered with a full overwrite format, then I recommend doing a blkdiscard of the entire card which will do max-length erasures from start to finish - with the side effect of wiping all data on the card. If this is awkward, then run fstrim (once) manually.

I don't recommend enabling fstrim by default.
Rockets are loud.
https://astro-pi.org

JumpZero
Posts: 1143
Joined: Thu Mar 28, 2013 7:35 pm
Location: 127.0.0.1

Re: RPi4 external USB3 SSD Enable and Check Trim

Mon Mar 16, 2020 5:26 pm

Hello,
jdb wrote:
Mon Mar 16, 2020 4:52 am
I don't recommend enabling fstrim by default.
Yes, it isn't enabled by default:

Code: Select all

$ sudo systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor preset: en
   Active: inactive (dead)
  Trigger: n/a
     Docs: man:fstrim
lines 1-5/5 (END)
.

So what is the best option for a SSD:
1 - as suggested above by @HawaiianPi : create the udev rules file for your USB SSD (or adapter) and issue a sudo systemctl start fstrim.timer command.

2 - use the discard option in /etc/fstab
The Debian wiki is a bit confusing
excerpt :
If desirable, enable the "discard" filesystem options for automatic online TRIM.
then
Alternatively, and often not recommended: Set "discard" mount option in /etc/fstab for the ext4 filesystem, swap partition, Btrfs, etc.

3 - is it the same for a SD card?

Thanks if you can answer.

pica200
Posts: 219
Joined: Tue Aug 06, 2019 10:27 am

Re: RPi4 external USB3 SSD Enable and Check Trim

Tue Mar 17, 2020 10:12 am

JumpZero wrote:
Mon Mar 16, 2020 5:26 pm
So what is the best option for a SSD:
1 - as suggested above by @HawaiianPi : create the udev rules file for your USB SSD (or adapter) and issue a sudo systemctl start fstrim.timer command.
There are quuite a few dodgy SATA <--> USB 3 adapters where uasp doesn't work properly so the weekly fstrim is probably a good idea to avoid slowdowns on deleting many files. Different story for plain SATA SSDs but the Pi 4 has no SATA.
JumpZero wrote:
Mon Mar 16, 2020 5:26 pm
2 - use the discard option in /etc/fstab
The Debian wiki is a bit confusing
excerpt :
If desirable, enable the "discard" filesystem options for automatic online TRIM.
then
Alternatively, and often not recommended: Set "discard" mount option in /etc/fstab for the ext4 filesystem, swap partition, Btrfs, etc.
They probably don't recommend it because people had issues in the past. As said discard makes sense if the SSD supports SATA 3.1 (they are all still advertised as SATA 3 but most if not all from recent years support 3.1). But again, this applies for native SATA.
JumpZero wrote:
Mon Mar 16, 2020 5:26 pm
3 - is it the same for a SD card?
jdb is correct. "TRIM" is not the same on SD cards as SSDs. It erases flash pages so they can be overwritten quickly next time (saving time by not having to erase first). The controller can also use this information to know what is used (contains data) or unused.

I'm not convinced personally the discard mount option will hurt SD cards. I had good experience with it and no card is slowing down here either. But it's up to you to decide. SD cards are cheap so you could take this as an opportunity to make a long term test discard vs. no discard and keep us updated on the results ;)

JumpZero
Posts: 1143
Joined: Thu Mar 28, 2013 7:35 pm
Location: 127.0.0.1

Re: RPi4 external USB3 SSD Enable and Check Trim

Tue Mar 17, 2020 1:17 pm

Hi!
@pica2000 thanks for your explanation, that's clear.
Actually after more reading I found that the Debian wiki has a link here
So in short the discard option in fstab versus weekly trim:
The discard option does a real time SSD operation at every file deletion and this costs time.
Running weekly trim is enough and offers some other advantages.
I quote the paragraph here under:
This is the most interesting part. Most people simply add the option “discard” in the mounting options at /etc/fstab. However, this means that every time you delete a file, the OS will be reporting in real-time to the SSD which blocks were occupied by that file and are not longer in use, and then the SSD will have to perform a defragmentation and deletion of those internal blocks, operation which will take an amount of time higher than desired.

In order to optimize the performance of the SSD, I strongly advise you to avoid doing the TRIM operation in real time (whenever a file is deleted) because you would be putting an unnecessary extra amount of work over the SSD. In other words: You should not enable the discard option in fstab.

Instead, what I recommend is to run a script periodically to tell the SSD which blocks are free with the command fstrim. Doing this operation daily or weekly is more than enough. This way we do not lose any performance due to TRIM when deleting files and we periodically keep informed the SSD about the free blocks.

Other advantages of the fstrim way are:

If you didn’t enabled correctly the TRIM support in the above layers of your setup, you will receive an error when executing fstrim. On the other hand, if you were using the discard option at fstab you wouldn’t have received any error and you would end thinking that you managed to get TRIM working properly when you didn’t.
If you delete a file by mistake (you know it happens), you can recover it before anacron runs your script fstrim. On the other hand, if you were using the discard-at-fstab option you wouldn’t have any chance of recovering the file, because the OS would have told the SSD to TRIM that blocks as soon as you deleted the file, and consequently the SSD has irreversibly destroyed such blocks.

pica200
Posts: 219
Joined: Tue Aug 06, 2019 10:27 am

Re: RPi4 external USB3 SSD Enable and Check Trim

Tue Mar 17, 2020 2:05 pm

Yes, it may still be slower than weekly fstrim even with native SATA (3.1) but the majority of the slowdown comes from command handling as i understand it. If you delete lots of files you will send a flood of TRIM commands to the SSD with discard. If the SSD can't take multiple commands at once (command queueing) the kernel has to wait for each TRIM to finish.

With a USB <--> SATA bridge in between you can't be certain it supports command queueing properly so weekly fstrim will be fine as recommended by the Wiki article.

lurk101
Posts: 231
Joined: Mon Jan 27, 2020 2:35 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Wed Mar 18, 2020 8:49 pm

Question: Does the fstrim.timer service trim only SSDs, or does it trim all trimable file systems (which would include the sdcard)?
Honesty, a truly frightening power.

Nitrax
Posts: 11
Joined: Sun Mar 15, 2020 4:06 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Wed Mar 18, 2020 9:11 pm

Don't use discard on SD card:

Quick benchmark:
RPi 4, 4GB root fs. data=writeback, commit=60,noatime
32GB Sandisk microSD A1

Code: Select all

discard on:

pi@arrakis:~/kbench $ time tar -xf linux-5.5.10.tar
real    1m26.613s
user    0m0.792s
sys     0m10.324s

pi@arrakis:~/kbench $ time rm -rf linux-5.5.10
real    7m45.680s
user    0m0.305s
sys     0m9.030s


discard off:

pi@arrakis:~/kbench $ time tar -xf linux-5.5.10.tar
real    1m22.648s
user    0m0.890s
sys     0m11.380s

pi@arrakis:~/kbench $ time rm -rf linux-5.5.10
real    0m5.150s
user    0m0.183s
sys     0m3.924s

lurk101
Posts: 231
Joined: Mon Jan 27, 2020 2:35 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Thu Mar 19, 2020 3:17 am

lurk101 wrote:
Wed Mar 18, 2020 8:49 pm
Question: Does the fstrim.timer service trim only SSDs, or does it trim all trimable file systems (which would include the sdcard)?
Answering my own question, it seems enabling fstrim.timer as shipped might not be such a good idea!

Code: Select all

pi@raspberrypi:~ $ cat /lib/systemd/system/fstrim.service    
[Unit]
Description=Discard unused blocks on filesystems in fstab
Documentation=man:fstrim(8)

[Service]
Type=oneshot
ExecStart=/sbin/fstrim -Av
That will include the SD cards.

Code: Select all

pi@raspberrypi:~ $ sudo fstrim -Av
/: 445.8 GiB (478686072832 bytes) trimmed on /dev/sda1
/boot: 199 MiB (208652800 bytes) trimmed on /dev/mmcblk0p1
Yep, it does on my PI4b. Apparently not a good idea to trim SD cards.
Probably should edit /lib/systemd/system/fstrim.service and change it to

Code: Select all

ExecStart=/sbin/fstrim -v /
Then

Code: Select all

systemctl daemon-reload
Honesty, a truly frightening power.

JumpZero
Posts: 1143
Joined: Thu Mar 28, 2013 7:35 pm
Location: 127.0.0.1

Re: RPi4 external USB3 SSD Enable and Check Trim

Thu Mar 19, 2020 8:45 am

Nitrax wrote:
Wed Mar 18, 2020 9:11 pm
Don't use discard on SD card:

Quick benchmark:
RPi 4, 4GB root fs. data=writeback, commit=60,noatime
32GB Sandisk microSD A1

Code: Select all

discard on:

pi@arrakis:~/kbench $ time tar -xf linux-5.5.10.tar
real    1m26.613s
user    0m0.792s
sys     0m10.324s

pi@arrakis:~/kbench $ time rm -rf linux-5.5.10
real    7m45.680s
user    0m0.305s
sys     0m9.030s


discard off:

pi@arrakis:~/kbench $ time tar -xf linux-5.5.10.tar
real    1m22.648s
user    0m0.890s
sys     0m11.380s

pi@arrakis:~/kbench $ time rm -rf linux-5.5.10
real    0m5.150s
user    0m0.183s
sys     0m3.924s
Very interesting!
This clearly demonstrates what is said in the article I quoted here above: the fstab option "discard" costs time:
7minutes45seconds vs 5seconds in your test to delete a file !!!

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2439
Joined: Thu Jul 11, 2013 2:37 pm

Re: RPi4 external USB3 SSD Enable and Check Trim

Thu Mar 19, 2020 9:37 am

Nitrax wrote:
Wed Mar 18, 2020 9:11 pm
Don't use discard on SD card:

Quick benchmark:
RPi 4, 4GB root fs. data=writeback, commit=60,noatime
32GB Sandisk microSD A1

Code: Select all

discard on:

pi@arrakis:~/kbench $ time tar -xf linux-5.5.10.tar
real    1m26.613s
user    0m0.792s
sys     0m10.324s

pi@arrakis:~/kbench $ time rm -rf linux-5.5.10
real    7m45.680s
user    0m0.305s
sys     0m9.030s


discard off:

pi@arrakis:~/kbench $ time tar -xf linux-5.5.10.tar
real    1m22.648s
user    0m0.890s
sys     0m11.380s

pi@arrakis:~/kbench $ time rm -rf linux-5.5.10
real    0m5.150s
user    0m0.183s
sys     0m3.924s
Oof. It looks like the discard is being done synchronously on file deletion which is even worse than background fstrim - delete implies block erase for each file deleted.
Rockets are loud.
https://astro-pi.org

pica200
Posts: 219
Joined: Tue Aug 06, 2019 10:27 am

Re: RPi4 external USB3 SSD Enable and Check Trim

Thu Mar 19, 2020 9:42 am

Well of course. Erase takes time. But you can still enable weekly fstrim for SD cards to avoid that slowdown.

If you take into account that write operations (to pre-erased pages) in turn will be faster this slowdown may not look as bad as it seems.

Return to “General discussion”