Post by Jean F. Martinelle
A few years ago, when SSDs were becoming popular, I remember
reading that they have have to be mounted differently to ordinary hard
drives, in order to make sure that data are to be spread evenly over all
the memory cells in the SSD, so that the wear associated with writing and
reading data is not concentrated in a small number of such cells.
Is this still the case, or can modern SSDs be mounted with lines
in /etc/fstab identical to the ones that would be used for ordinary hard
I went round the same loop looking for info on ssd TRIM a few weeks ago.
I found this great post by Ted Tso, who is the lead designer/developer
of the linux Ext- series of filesystems, as such Ted is the real
authority on this subject. It's from here:-
But he has given such a good explanation that I've copied it in verbatim
in case the link gets deleted. I'm sure he won't mind!
Ted Tso quote starts here:-
This is an old thread, but just to make sure correct information is out there.
TRIM or DISCARD (depending on whether you have a SATA or SCSI disk) is a hint
to the storage device. It is used not just for SSD's, but also for Thin
Provisioned volumes on enterprise storage arrays, such as those sold by EMC.
(Linux has an implementation of this called dm-thin for local storage). There
are multiple reasons why fstrim is the preferred mechanism for issuing trims.
First, many SSD's and Thin Provisioning implementation can more efficiently
process bulk trim commands. In particular, some storage arrays will ignore
trims that are smaller than a megabyte, because the allocation granularity of
the Thin Provisioning system is a megabyte, and some/many enterprise storage
arrays don't track sub-allocation usage. Since the trim command is a hint, it
is always legal to ignore a trim command, and so if you delete a large source
tree, where none of the files are larger than a megabyte, depending on whether
or how the OS batches the discard commands, the TRIM commands may have no
effect if they are issued as the files are deleted.
Secondly, the trim command is a non-queueable command for most SATA SSD's
(there are new SSD's that implement a new, queueable TRIM command, but they are
rare, and while the Samsung EVO SSD's tried introducing the queuable trim via a
firmware update, it was buggy, and had to be blacklisted and later withdrawn
because it caused to file system and data corruption, and Samsung determined it
could not be fixed via a firmware update). A non-queueable command means that
the TRIM command has to wait for all other I/O requests to drain before it can
be issued, and while it is being issued, no other I/O requests can be processed
by the SSD. As such, issuing TRIM commands can interfere with more important
I/O requests. (e.g., like those being issued by a database for a production
For these two reasons, on Linux the recommended way to use TRIM is to use the
fstrim command run out of cron, so that during an idle period the TRIM commands
can be issued for all of the unused areas on the disk. Typically once a week is
plenty; some people will go every night, or even once a month, since it is very
workload dependent. This causes much less of a performance impact on production
traffic, and for thin provisioning systems which use a large allocation
granularity, it is much more effective. Note that this has nothing to do with a
particular file system or OS implementation, but is much more about fundamental
issues of how storage devices respond to TRIM commands, so what is best
practice for Linux would also be a good thing to do on FreeBSD, if possible.
Note that one other scenario when fstrim is useful is before creating a
snapshot or image on a cloud system, such as Google Compute Engine. The TRIM
command tells the VM's storage subsystem which blocks are in use, and which are
not in use. This allows the resulting snapshot and image to (a) be created more
quickly, and (b) be cheaper since for snapshots and images, you are charged
only for the blocks which are in use, and not the size of the source disk from
which the snapshot or image was created. (Indeed, this is how I came across
this thread; I was assisting the e2fsprogs Ports maintainer on fixing some
portability problems with e2fsprogs that came up with FreeBSD-11, and in order
to do that I had to create some FreeBSD 11-rc2 GCE VM instances, and while
trying to create backup snapshots of my FreeBSD-10 and FreeBSD-11 VM's, I tried
to determine if there was a fstrim-equivalent for FreeBSD, since the GCE VM
images published by the FreeBSD organization don't enable TRIM by default on
the file system, and I like to optimize any snapshots or images I create.)
P.S. Ext4's discard feature can be useful, but only in very highly specialized
use cases. For example, if you have a PCI-e attached flash device where the FTL
is implemented as a host OS driver, sending discards as soon as the file is
deleted is useful since it is fast (the FTL is running on the host, and it
isn't subject to the limitations of the SATA command), and it can reduce the
FTL's GC overhead, both in terms of reducing flash writes and CPU and memory
overhead of the FTL on the host. However, aside from these specific instances,
sending bulk trims of unused space, triggered out of cron once a week or so, is
what I generally recommend as best practice for most systems.
P.P.S. In Linux the fstrim functionality is implemented in the kernel, and is
supported by most of the major file systems (including ext4, btrfs, and xfs).
This means that even though fstrim is triggered from userspace, typically via a
sysadmin command or out of cron, it is safe to run on a mounted file system,
since the kernel locks out allocations from the block/allocation/cylinder group
while the TRIM commands are in flight for that particular part of the disk. It
would be nice if FreeBSD had a similar feature since it is helpful for use
cases beyond SSD's, including on guest VM's.
End of quote.
Gnd -|o----|- Vcc Hey computer, what's the weather in Sydney?
trig -| 555 |- dschrg $ finger o:***@graph.no|tail -1|espeak
o/p -| |- thrsh
rst -|-----|- cntrl Steve555