On Mon, 12 Apr 2010, Tomas Ögren wrote:
For flash to overwrite a block, it needs to clear it first.. so yes,
clearing it out in the background (after erasing) instead of just before
the timing critical write(), you can make stuff go faster.
Yes of course. Properly built SSDs include considerable extra space
to support wear leveling, and this same space may be used to store
erased blocks. A block which is "overwritten" can simply be written
to a block allocated from the extra free pool, and the existing block
can be re-assigned to the free pool and scheduled for erasure. This
is a fairly simple recirculating algorithm which just happens to
also assist with wear management.
Filesystem blocks are rarely aligned and sized to match underlying
FLASH device blocks so FLASH devices would need to implement fancy
accounting in order to decide when they should actually erase a FLASH
block. Erasing a FLASH block may require moving some existing data
which was still not erased. It is much easier to allocate a
completely fresh block, update it as needed, and use some sort of
ordered "atomic" operation to exchange the blocks so the data always
exists in some valid state. Without care, existing data which should
not be involved in the write may be destroyed due to a power failure.
This is why it is not extremely useful for Solaris to provide support
for the "Windows 7 TRIM" command.
Really low-grade devices might not have much smarts or do very good
wear leveling, and these devices might benefit from the Windows 7 TRIM
command.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
