Talk:Solid state drive
Don't use noop
The noop scheduler will perform slow but as a result it will greatly frees up CPU cycles. This in the real world will not increase the speed of your read/writes compared to CFS but instead consume less CPU resources. You can benchmark the deadline scheduler which MAY increase performance in some circumstances. By real world benchmarks, I mean anything but hdparm. —This unsigned comment is by Tama00 (talk) 22:38, 21 December 2011. Please sign your posts with ~~~~!
- Interesting assertion... do you have any data or a source to back it up?
- Graysky 17:20, 21 December 2011 (EST)
- It seems that the cfq scheduler already knows what to do when SSD is detected, so there is no use to change it.
- raymondcal 2012, may 29
- CFQ has some optimizations for SSDs and if it detects a non-rotational media which can support higher queue depth (multiple requests at in flight at a time), then it cuts down on idling of individual queues and all the queues move to sync-noidle tree and only tree idle remains. This tree idling provides isolation with buffered write queues on async tree.
- https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt
- ushi 2013, November 03
- So does anyone have any good data? My research says deadline is best and that "cfq has some optimizations" doesn't mean it's better than others.
- MindfulMonk (talk) 22:38, 5 July 2014 (UTC)
TRIM and RAID
The wiki article within the warning in the section Enable continuous TRIM by mount flag says: A possible patch has been posted on July 19, 2015."
The quoted article seems to be saying that there is a serious kernel bug which impacts when SSD's are being used with linux software raid.
Is that a confirmed kernel bug? If it is then shouldnt the wiki point this out? —This unsigned comment is by Sja1440 (talk) 27 September 2015 08:26. Please sign your posts with ~~~~!
- The bug was manifested for particular brand SSD bios only, which were blacklisted. Since TRIM is a standard and other brands work fine, this issue was not regarded a kernel bug to my knowledge. Nonetheless, they may (have) merge(d) the patch to work-around the bios bugs. If someone has a related bug report where it is tracked or kernel commit, it would be useful to add, I agree. -Indigo (talk) 09:23, 27 September 2015 (UTC)
- I found this Slashdot discussion (linked with [1]) where there's a link to a kernel commit, although they're talking of a bug in the firmware too, and in fact the devices seem to be still blacklisted. — Kynikos (talk) 02:26, 28 September 2015 (UTC)
- Samsung's patch about data corruption are now merged, but full blacklist still here in Linux 4.5 https://github.com/torvalds/linux/blob/v4.5/drivers/ata/libata-core.c#L4223 for a lot of SDD brand, in particular all the popular Samsung 8 series (840|850 EVO|PRO). I still cannot find any information about the source issue and when it will be whitelisted. The article should warn user that all those SSD models should be avoided until a solution. Note that also --Nomorsad (talk) 11:03, 26 March 2016 (UTC)
- The article does warn; I have updated with your 4.5 link, thanks for follow-up. They added one more drive model to the blacklist since then.[2] --Indigo (talk) 11:19, 26 March 2016 (UTC)
fstrim, btrfs and other fs
IMO, the table with trim support should note that running fstrim on btrfs produces different output than on other filesystems. If I run fstrim multiple times in a row for example on ext4, the first time I get "freed X bytes", and on the consequent runs I get "freed 0 bytes" and the subsequent runs are done immediately. On btrfs, however, I always get the same number and it takes the same time as the first run. I didn't tried on other filesystems than these two, but it can be confusing and suggest that there is some misconfiguration for users who are not aware of this. --Zopper (talk) 12:17, 1 Sep 2016 (UTC)
fstrim on non-ssd, e.g. QEMU
I'm not sure if this fit's into this articel, or better another, but I think it should be mentioned, that the trim could be useful on non-ssd disks, e.g. on QEMU disks with harddrives. This is of course not the same trim like on ssd, but it't the same intention: inform the storage system about unused blocks, e.g. to avoid defragmenation, shrink the image. Example from an KVM system with QEMU disks, labeled not as SSD but with SAS storage on the product page:
$ lsblk --discard NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 4K 1G 0 ├─sda2 0 4K 1G 0
$ sudo fstrim -v -a /: 390,8 MiB (409780224 bytes) trimmed on /dev/sda2
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0-part2 -> ../../sda2
Ua4000 (talk) 18:00, 25 January 2021 (UTC)
Fstrim doesn't run on mounted drives that have been mounted via systemd-mount units?
The Article states "The util-linux package provides fstrim.service and fstrim.timer systemd unit files. Enabling the timer will activate the service weekly. The service executes fstrim(8) on all mounted filesystems on devices that support the discard operation."
I just checked my journal to see if periodic fstrim works as supposed by running journalctl -u fstrim i then noticed that only devices mounted via fstab seems to be trimmed since it would say: Finished Discard unused blocks on filesystems from /etc/fstab. Is the Wiki wrong about this?
Noclueguy (talk) 17:15, 4 March 2024 (UTC)
- Default behavior is changed in upstream at v2.33 and later modified in v2.36.
- It currently reads
/etc/fstabfirst, then tries/proc/self/mountinfoif fstab is unavailable or empty. Piroro-hs (talk) 07:20, 7 March 2024 (UTC) - This is really an issue:
- If you rely on systemd-gpt-auto-generator and therefore have no entries for / and /boot in your fstab but any others for x-systemd.automounts like nfs-shares e.g. systemd fstrim service will do nothing as it is invoked with '--listed-in /etc/fstab:/proc/self/mountinfo' .
- According to man page for fstrim 'The evaluation of the list stops after first non-empty file.' - which is the fstab in this case. T1m.t0nne (talk) 21:59, 9 March 2026 (UTC)
"External SSD with TRIM support" section could potentially brick the drive
Solid state drive#External SSD with TRIM support
See https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi/
> Warning: A few devices seemed to indicate they supported TRIM in firmware, like my Arcanite USB 3.1 Flash Drive... but when I tried enabling it I got a few errors. Then I tried running fstrim -v / on a whim, and ended up corrupting the drive's firmware, to the point it won't mount and can't be formatted anymore. So make sure you have a backup of any important data before you try on a drive that might not actually support TRIM! Teohhanhui (talk) 19:48, 4 January 2026 (UTC)
More specific path in /sys/block/ to get idVendor and idProduct
Following the instructions in #External SSD with TRIM support section, I got stuck at the step of getting idVendor and idProduct.
$ cat /sys/block/sdX/../../../../../../idVendor $ cat /sys/block/sdX/../../../../../../idProduct
This simply results in "No such file or directory" error (of course I replaced X with the drive letter). The text was added in the revision 581736. And while it says you can get this info from lsusb, it would be nice to specify the exact path you need to check in /sys/block to find this out. Ashark (talk) 13:01, 17 January 2026 (UTC)
- These commands work on my SSDs — andreymal (talk) 15:35, 17 January 2026 (UTC)
- Hmm. Interesting. I tried with different drive, and the command indeed works. But for others - does not. See:
::❯ sudo ls /sys/block/sdb/../../../../../.. # <- for sdb, there _is_ idVendor ::2-3:1.0 bcdDevice bDeviceProtocol bMaxPacketSize0 bNumInterfaces configuration devnum ep_00 idVendor maxchild power removable serial tx_lanes version ::authorized bConfigurationValue bDeviceSubClass bMaxPower bos_descriptors descriptors devpath firmware_node ltm_capable physical_location product remove speed uevent ::avoid_reset_quirk bDeviceClass bmAttributes bNumConfigurations busnum dev driver idProduct manufacturer port quirks rx_lanes subsystem urbnum ::❯ ::
::❯ sudo ls /sys/block/sda/../../../../../.. # <- for sda, there _is no_ idVendor ::aer ata3 broken_parity_status d3cold_allowed driver_override irq local_cpus numa_node remove resource1 resource5 subsystem_vendor ::ari_enabled ata4 class device enable label modalias power rescan resource2 revision uevent ::ata1 ata5 config dma_mask_bits firmware_node link msi_bus power_state resource resource3 subsystem vendor ::ata2 ata6 consistent_dma_mask_bits driver index local_cpulist msi_irqs remapped_nvme resource0 resource4 subsystem_device ::
- Seems that depends on individual product. Ashark (talk) 15:49, 17 January 2026 (UTC)