On 12/23/2010 7:57 AM, Deano wrote:
In an ideal world, if we could obtain details on how to reset/format blocks of
a SSD, we could do it automatically running behind the ZIL. As a log its going
in one direction, a background task could clean up behind it, making the
performance lowing over time a non-issue for the ZIL. A first start may be
calling unmap/trim on those blocks (which I was surprised to find in the source
is already coded up in the SATA driver, just not used yet) but really a reset
would be better.
But as you say a tool to say if its need doing would be a good start. They
certainly exist in closed source form...
Deano
-----Original Message-----
From: zfs-discuss-boun...@opensolaris.org
[mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Ray Van Dolson
Sent: 23 December 2010 15:46
To: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] Looking for 3.5" SSD for ZIL
On Thu, Dec 23, 2010 at 07:35:29AM -0800, Deano wrote:
If anybody does know of any source to the secure erase/reformatters,
I’ll happily volunteer to do the port and then maintain it.
I’m currently in talks with several SSD and driver chip hardware
peeps with regard getting datasheets for some SSD products etc. for
the purpose of better support under the OI/Solaris driver model but
these things can take a while to obtain, so if anybody knows of
existing open source versions I’ll jump on it.
Thanks,
Deano
A tool to help the end user know *when* they should run the reformatter
tool would be helpful too.
I know we can just wait until performance "degrades", but it would be
nice to see what % of blocks are in use, etc.
Ray
AFAIK, all the reformatter utilities are closed-source, direct from the
SSD manufacturer. They talk directly to the drive firmware, so they're
decidedly implementation-specific (I'd be flabberghasted if one worked
on two different manufacturers' SSDs, even if they used the same basic
controller). Many are DOS-based.
As Christopher noted, you'll get a drop-off in performance as soon as
you collect enough sync writes to have written (in the aggregate)
slightly more than the total capacity of the SSD (including the "extra"
that most SSDs now have).
That said, I would expect full TRIM support to possibly make this
better, as it could free up partially-used pages more frequently, and
thus increasing the time before performance drops (which is due to the
page remapping/reshuffling demands on the SSD controller).
But, yes, SSDs are inherently less fast than DRAM. They're utility is
entirely dependent on what your use case (and performance demands) are.
The longer-term solution is to have SSDs change how they are designed,
moving away from the current one-page-of-multiple-blocks as the atomic
entity of writing, and straight to a one-block-per-page setup. Don't
hold your breath.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
