[zfs-discuss] Lower latency ZIL Option?: SSD behind Controller BB Write Cache

taemun
Fri, 28 Jan 2011 15:33:56 -0000

Comments below.

On 29 January 2011 00:25, Edward Ned Harvey <
opensolarisisdeadlongliveopensolaris at nedharvey.com> wrote:

> This was something interesting I found recently.  Apparently for flash
> manufacturers, flash hard drives are like the pimple on the butt of the
> elephant. A vast majority of the flash production in the world goes into
> devices like smartphones, cameras, tablets, etc.  Only a slim minority goes
> into hard drives.

http://www.eetimes.com/electronics-news/4206361/SSDs--Still-not-a--solid-state--business
~6.1 percent for 2010, from that estimate (first thing that Google turned
up). Not denying what you said, I just like real figures rather than random
hearsay.


> As a result, they optimize for these other devices, and
> one of the important side effects is that standard flash chips use an 8K
> page size.  But hard drives use either 4K or 512B.
>
http://www.anandtech.com/Show/Index/2738?cPage=19&all=False&sort=0&page=5
Terms: "page" means the smallest data size that can be read or
programmed
(written). "Block" means the smallest data size that can be erased.
SSDs
commonly have a page size of 4KiB and a block size of 512KiB. I''d take
Anandtech''s word on it.

There is probably some variance across the market, but for the vast
majority, this is true. Wikipedia''s
http://en.wikipedia.org/wiki/Flash_memory#NAND_memories says that common
page sizes are 512B, 2KiB, and 4KiB.

The SSD controller secretly remaps blocks internally, and aggregates
small
> writes into a single 8K write, so there''s really no way for the OS
to know
> if it''s writing to a 4K block which happens to be shared with
another 4K
> block in the 8K page.  So it''s unavoidable, and whenever it
happens, the
> drive can''t simply write.  It must read modify write, which is
obviously
> much slower.
>
This is be true, but for 512B to 4KiB aggregation, as the 8KiB page
doesn''t
exist. As for writing when everything is full, and you need to do an
erase..... well this is where TRIM is helpful.

Also if you look up the specs of a SSD, both for IOPS and/or
sustainable
> throughput...  They lie.  Well, technically they''re not lying
because
> technically it is *possible* to reach whatever they say.  Optimize your
> usage patterns and only use blank drives which are new from box, or have
> been fully TRIM''d.  Pfffft...  But in my experience, reality is
about 50%
> of
> whatever they say.
>
> Presently, the only way to deal with all this is via the TRIM command,
> which
> cannot eliminate the read/modify/write, but can reduce their occurrence.
> Make sure your OS supports TRIM.  I''m not sure at what point ZFS
added
> TRIM,
> or to what extent...  Can''t really measure the effectiveness
myself.
>
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6957655
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6957655>

> Long story short, in the real world, you can expect the DDRDrive to crush
> and shame the performance of any SSD you can find.  It''s mostly a
question
> of PCIe slot versus SAS/SATA slot, and other characteristics you might care
> about, like external power, etc.

Sure, DDR RAM will have a much quicker sync write time. This isn''t
really a
surprising result.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110129/5f4b3d62/attachment-0001.html>