Gordan Bobic wrote:
TRIM lets the OS tell the disk which blocks are not in use anymore, and
thus don't have to be copied during a rewrite of the blocks.
Wear-leveling is the SSD making sure all blocks are more or less equally
written to avoid continuous load on the same blocks.
And thus it is impossible to do wear leveling when all blocks have been
written to once without TRIM. So I'd say that in the long term, without
TRIM there is no wear leveling. That makes them pretty related.
I'm no expert of SSDs, however
1- I think the SSD would rewrite once-written blocks to other locations,
so to reuse the same physical blocks for wear levelling. The
written-once blocks are very good candidates because their write-count
is "1"
2- I think SSDs show you a smaller usable size than what they physically
have. In this way they always have some more blocks for moving data to,
so to free blocks which have a low write-count.
3- If you think #2 is not enough you can leave part of the SSD disk
unused, by leaving unused space after the last partition.
Actually, after considering #1 and #2, I don't think TRIM is really
needed for SSDs, are you sure it is really needed? I think it's more a
kind of optimization, but it needs to be very fast for it to be useful
as an optimization, faster than an internal block rewrite by the SSD
wear levelling, and so fast as SATA/SAS command that the computer is not
significantly slowed down by using it. Instead IIRC I read something
about it being slow and maybe was even requiring FUA or barrier or
flush? I don't remember exactly.
There is one place where TRIM would be very useful though, and it's not
for SSDs, but it's in virtualization: if the Virtual Machine frees
space, the VM file system should use TRIM to signal to the host that
some space is unused. The host should have a way to tell its filesystem
that the VM-disk-file has a new hole in that position, so that disk
space can be freed on the host for use for another VM. This would allow
much greater overcommit of disk spaces to virtual machines.
There's probably no need for "TRIM" support itself on the host
filesystem, but another mechanism is needed that allows to sparsify an
existing file creating a hole in it (which I think is not possible with
the filesystems syscalls we have now, correct me if I'm wrong). There
*is* need for TRIM support in the guest filesystem though.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
