[zfs-discuss] Pure SSD Pool

Brandon High
Tue, 12 Jul 2011 17:35:53 -0000

On Tue, Jul 12, 2011 at 7:41 AM, Eric Sproul <esproul at omniti.com>
wrote:
> But that''s exactly the problem-- ZFS being copy-on-write will
> eventually have written to all of the available LBA addresses on the
> drive, regardless of how much live data exists. ?It''s the rate of
> change, in other words, rather than the absolute amount that gets us
> into trouble with SSDs. ?The SSD has no way of knowing what blocks

Most "enterprise" SSDs use something like 30% for spare area. So a
drive with 128MiB (base 2) of flash will have 100MB (base 10) of
available storage. A consumer level drive will have ~ 6% spare, or
128MiB of flash and 128MB of available storage. Some drives have 120MB
available, but still have 128 MiB of flash and therefore slightly more
spare area. Controllers like the Sandforce that do some dedup can give
you even more effective spare area, depending on the type of data.

When the OS starts reusing LBAs, the drive will re-map them into new
flash blocks in the spare area and may perform garbage collection on
the now partially used blocks. The effectiveness of this depends on
how quickly the system is writing and how full the drive is.

I failed to mention earlier that ZFS''s write aggregation is also
helpful when used with flash drives since it can help to ensure that a
whole flash block is written at once. Increasing the ashift value to
4k when the pool is created may also help.

> Now, others have hinted that certain controllers are better than
> others in the absence of TRIM, but I don''t see how GC could know
what
> blocks are available to be erased without information from the OS.

The changed LBAs are remapped rather than overwritten in place. The
drive knows which LBAs in a flash block have been re-mapped, and can
do garbage collection when the right criteria are met.

-B

--
Brandon High : bhigh at freaks.com