Notices


Reply
Thread Tools
Posts: 407 | Thanked: 933 times | Joined on Jan 2012 @ Enschede, The Netherlands
#1
Current SSD's support TRIMming, where the OS tells the drive whenever data blocks are no longer used and can be freed by the drive. It helps with longevity and performance, as the drive has empty blocks available for wear leveling and ready to write new data to.

Linux supports this since many years, and Btrfs has a mount option to enable it.

On the Jolla1, this does not appear to be enabled:

Code:
[nemo@Sailfish ~]$ cat /sys/block/mmcblk0/queue/discard_zeroes_data 
0
(remarkably, it it is enabled on the µSD-card?!)
Code:
[nemo@Sailfish ~]$ cat /sys/block/mmcblk1/queue/discard_zeroes_data 
1
Linux normally has the command fstrim, which invokes TRIM on demand. However, this command isn't available on SailfishOS.

edit: not sure whether discard_zeroes_data actually means TRIM is supported. On my two home machines with SSD with TRIM support it also says "0", even though an "fstrim" actually seems to do something. On Ubuntu, fstrim is scheduled to run once a week by default.

Questions:
  • Could it be enabled for btrfs on Jolla1? Note the btrfs mount option "ssd", which is enabled on J1, does not imply TRIM/discard.
  • Would it actually help?

Last edited by Fuzzillogic; 2017-10-15 at 21:49.
 

The Following 6 Users Say Thank You to Fuzzillogic For This Useful Post:
Posts: 407 | Thanked: 933 times | Joined on Jan 2012 @ Enschede, The Netherlands
#2
Digging a bit further into this, the source code of fstrim uses discard_granularity to see whether trim is supported.

And lo and behold:

Code:
[nemo@Sailfish ~]$ cat /sys/block/mmcblk0/queue/discard_granularity 
524288
I'm wary to experiment with this on my JP1, as this is my only and primary mobile, and I don't want to end up with the entire flash storage being trimmed, leaving me with exactly 0 bits of data on the device…
 

The Following 2 Users Say Thank You to Fuzzillogic For This Useful Post:
Posts: 169 | Thanked: 736 times | Joined on Dec 2014 @ Earth
#3
Originally Posted by Fuzzillogic View Post
I'm wary to experiment with this on my JP1, as this is my only and primary mobile, and I don't want to end up with the entire flash storage being trimmed, leaving me with exactly 0 bits of data on the device…
Also, TRIM comes with a performance penalty because nearly all current hardware except some top end SSD comes without support for queued trims.

Means that in case of discard, you can just emit the TRIM command on queue.

You need to flush the whole command queue, wait of it to get written on the flash media, then issue the TRIM command, wait for completion, and then resume normal operation.

Each discard is accompanied with a delay.



The best wait to use TRIM is as part of your "normal btrfs maintenance" routine :
  • run 'btrfs scrub start -B /' to see if the data on the root is clean
  • run 'btrfs balance start -v -dusage=60 -musage=60 /' to balance the chunks and avoid the "enosp" situation.
  • run 'fstrim /' to reclaim back the flashmedia's erase block that werre freed from the balanced btrfs chunks.
 

The Following 4 Users Say Thank You to DrYak For This Useful Post:
Posts: 407 | Thanked: 933 times | Joined on Jan 2012 @ Enschede, The Netherlands
#4
AFAIK, the delay caused by TRIM is indeed the reason that distributions like Ubuntu by default schedule a fstrim once a week. On the JP1, a btrfs balance is also scheduled to run once a week (Tue 3:00, in /lib/systemd/system/btrfs-balancer.timer). Running a fstrim afterwards would be ideal, I guess. Well, it seems it was scheduled, as the timer is now disabled?!

But I thought fstrim wasn't available on Sailfish. I was wrong, it is available, in /sbin/fstrim, it just isn't in the path. So screw it, I did a btrfs balance and I ran fstrim afterwards:

Code:
[root@Sailfish nemo]# /sbin/fstrim -a -v
/opt/alien/media/sdcard/1d87f0ae-05cb-4eb5-a04a-c0a7e0455980: 0 B (0 bytes) trimmed
/opt/alien/home: 115.9 MiB (121470976 bytes) trimmed
/drm: 0 B (0 bytes) trimmed
/persist: 0 B (0 bytes) trimmed
/var/systemlog: 0 B (0 bytes) trimmed
/: 115.9 MiB (121470976 bytes) trimmed
Actually I ran it before, but forgot the -v Either way, it was quick: seconds, which is much faster than on the OCZ Vertex 3 and 4 I have here. And when I run it again and again, it always claims 115.9MiB are trimmed.

So, I can't tell whether or not it does something useful. And whether it helps with the occasional temporary freeze I have remains to be seen. But it seems it doesn't break things, as far as I can tell yet anyway.
 

The Following 2 Users Say Thank You to Fuzzillogic For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 03:35.