TRIM support?

nortonham

How is trim support for SSD's in the 3 major BSD's generally?

JuvenalUrbino

nortonham The first consideration to make is that while TRIM will most likely improve write performance by allowing preemptive garbage collection (so files can be directly written without having to reclaim free pages), it is not completely devoid of downsides. In fact, when acting in background (as a static mount option), TRIM may also lead to a paradoxical increased write latency, or even lead to data corruption on certain known products, whose firmware either misreports support for queued TRIM or has critical bugs in its implementation.

For these reasons, TRIM may be more safely and efficiently implemented ad hoc by issuing the command to discard unused blocks during periodical maintenance, rather than leaving it persistently active as a mount option, which forces it to be invoked after every single file deletion. On Linux this is achieved with fstrim(8) and can be automatized via cron jobs.

Now, speaking of the 3 major BSDs:

FreeBSD introduced TRIM support in 2010 ; the implementation has been more broadly tested, enough to be considered reliable and solid. UFS only supports continuous TRIM, wich can be activated with tunefs(8) (e.g. tunefs -t enable /dev/ada0p2) . No equivalent of fstrim exists for UFS on FreeBSD. ZFS supports either continuous discarding (as a sysctl valuevfs.zfs.trim.enabled=1), or occasional trimming via zpool-trim(8), thus factually providing a true BSD alternative for fstrim. I think zpool trim was a non-upstream ZoL-only feature, so it should be available on FreeBSD 13.0+ only, following the OpenZFS rebasing. I presume that a side consequence of this is that zpool-trim is not present on NetBSD's ZFS, since the latter is still based on the ZFS version found in illumos-base (too many assumptions... @nia please correct me here).
NetBSD introduced support for TRIM in 2012, but it's still marked experimental since no serious work has been done ever since on the code. The implementation would probably benefit from broader testing / bug reports, at which point it may become clear it needs a major rework.To sum up, use it at your own risk. I've tested it personally a couple of times on personal laptops and it did its job, while I didn't encounter any noticeable issue. ATA TRIM is supported as discard mount option for wd* and md* (for testing) devices, to be added in fstab, just like in Linux. No fstrim equivalent for periodical trimming. If your device supports TRIM, then atactl wd* identify will return "TRIM supported" under the "Serial ATA capabilities" section. I don't know if UNMAP/discarding for sd* devices is supported too. TRIM is not to be activated in conjunction with journaling. If memory serves me right, on FreeBSD you can't have TRIM in conjunction with SU+J.
OpenBSD doesn't support TRIM as far as I know.

bsduck

Enabled by default on FreeBSD.

Available on NetBSD (mount option discard) but still marked experimental and incompatible with journaling (mount option log).

No TRIM support at all on OpenBSD.

nortonham

bsduck

Thank you. When you say it is default on FreeBSD, does that there is no configuration necessary by the end user?

edit: looking at an old fbsd forum post from 2016 it looks like the user doesn't really need to don anything to have trim support

Alexander88207

bsduck

On FreeBSD, ZFS have trim enabled by default but not with UFS.

nortonham

JuvenalUrbino

Thanks for the info, it's very helpful.

Looking at that link to the linux kernel, I don't see my device in there, but will obviously double check.

Your link to the FreeBSD forums is the same I read while researching.

It sounds like FreeBSD with ZFS is the best way to use TRIM in any of the BSD's. You mentioned drawbacks to using TRIM; are there any drawbacks to not using it?

Do you know the reason why Open doesn't have trim?

Thanks again for responding.

bsduck

Alexander88207 On FreeBSD, ZFS have trim enabled by default but not with UFS.

Really? Good to know, I thought this would be enabled by default by the installer. I'm a ZFS user so I can't tell from personal experience.

JuvenalUrbino No equivalent of fstrim exists for UFS on FreeBSD.

You can use fsck_ffs -E :

Clear unallocated blocks, notifying the underlying device that
they are not used and that their contents may be discarded. This
is useful for filesystems which have been mounted on systems
without TRIM support, or with TRIM support disabled, as well as
filesystems which have been copied from one device to another.

JuvenalUrbino

nortonham Looking at that link to the linux kernel, I don't see my device in there, but will obviously double check.

Linked the wrong chunck (whitelisted devices). Here you are. The Linux kernel enforces sending non-queued TRIM commands to the following devices:

/* devices that don't properly handle queued TRIM commands */
	{ "Micron_M500IT_*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Micron_M500_*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Crucial_CT*M500*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Micron_M5[15]0_*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Crucial_CT*M550*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Crucial_CT*MX100*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Samsung SSD 840*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Samsung SSD 850*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Samsung SSD 860*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM |
						ATA_HORKAGE_NO_NCQ_ON_ATI, },
	{ "Samsung SSD 870*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM |
						ATA_HORKAGE_NO_NCQ_ON_ATI, },
	{ "FCCT*M500*",			NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },

It sounds like FreeBSD with ZFS is the best way to use TRIM in any of the BSD's.

I see no reason for zpool trimming not to land on NetBSD too as soon as the driver gets updated/rebased. I'm more concerned about FFSv2 though, wish the implementation received more attention (be revised and declared stable or be removed).

You mentioned drawbacks to using TRIM; are there any drawbacks to not using it?

To my amateurish understanding, TRIM preemptively tells ffs_alloc() to discard (not move to a free block before erasing) invalid data pages during garbage collection, allowing the SSD's controller to more efficiently manage the storage space available for data.
By preventing the unnecessary moving of invalid data pages before erasing unused blocks, TRIM optimizes disk space allocation and reduces the amount of P/E cycles.
This in turn results in higher write throughput (no need for read-erase-modify before writing) especially on a close to full and highly fragmented disk, lower write amplification (especially in case of misaligned sectors), and, as a side consequence, slower wearing out (prolonged lifespan).

So, to my eyes, it's not like TRIM is a totally optional and completely negligible feature. It wouldn't have been implemented on most modern operating systems otherwise.

Do you know the reason why Open doesn't have trim?

See those threads on openbsd-misc:

Just my two cents, why bother?

SSDs are much better these days, then when they first arrived.
How long do we expect them to last? They for sure outperform spinning disks and probably last as long in a laptop.

Personally, I don't care about TRIM, back-ups is all there's needed. At some point the drive is going to fail but, with 120 Gb at about $20, I don't bother.

I've been using this SSD for over 4 years now, I build and test packages for pkgsrc on it daily and the only thing I have is noatime and nodevmtime in fstab. Honestly, I'm hoping it fails at some point, because I really need a larger disk but, can't justify it for myself, while this one still works.

All in all, I have nothing against TRIM, I simply don't bother because, I don't see the point. So, I wouldn't pick my OS based on TRIM support.

nortonham

Thanks for the feedback.

I asked about TRIM because I upgraded a T420 and replaced the old HDD with a SSD, and wasn't sure if TRIM mattered or not, If it doesn't matter then I'll just install whatever without worrying about it. It's a brand new SSD so in the short term I'm not really that worried, I just assumed (rightly 😃 ) that this was the best place to ask about best practices.

Now that I have the SSD I just need the RAM to arrive, follow it up with a new screen and an i7 and this t420 will be a very modern laptop......

nortonham If it doesn't matter then I'll just install whatever without worrying about it.

I didn't say this. What I said was, it doesn't matter to me.
Above all, it would not make me choose another OS but, it might be important for somebody else.

nortonham

Yes, I understand what you wrote.

nortonham

JuvenalUrbino

Thanks again for the help/info.

nia

For those interested in such things, NetBSD -current recently gained a blkdiscard command, which can be used to manually TRIM a disk:

https://freshbsd.org/netbsd/src/commit/clfEmUjrmKROtFrD

Mosfet

nia Does the ZFS implementation on NetBSD support TRIM?
If ZFS root is possible (in the upcoming 10.0 release, which AFAIK is not branched yet) and ZFS supports TRIM, that would be awesome! 😃

nia

Mosfet I don't know

JuvenalUrbino

Mosfet If ZFS root is possible

It is possible already, see the relevant Root on ZFS entry on the wiki; while I haven't tried this myself, it seems relatively straightforward. Similarly to CGD-encrypted root, one has to manually take care of partitioning, put the initial ramdisk in the boot partition and configure boot.cfg accordingly.

However, if you're speaking of ZFS being integrated in the installer before the next major release, I wouldn't get my hopes to high.

Mosfet

JuvenalUrbino Yep, I mean the latter. Install on a newly created ZFS pool, as part of the installation.