On Wed, 17 Mar 2010, Brad Nicholson wrote:
On Wed, 2010-03-17 at 14:11 -0400, Justin Pitts wrote:
On Mar 17, 2010, at 10:41 AM, Brad Nicholson wrote:
On Wed, 2010-03-17 at 09:52 -0400, Justin Pitts wrote:
FusionIO is publicly claiming 24 years @ 5TB/day on the 80GB SLC device, which
wear levels across 100GB of actual installed capacity.
http://community.fusionio.com/forums/p/34/258.aspx#258
20% of overall capacity free for levelling doesn't strike me as a lot.
I don't have any idea how to judge what amount would be right.
Some of the Enterprise grade stuff we are looking into (like TMS RamSan)
leaves 40% (with much larger overall capacity).
Also, running that drive at 80GB is the "Maximum Capacity" mode, which
decreases the write performance.
Very fair. In my favor, my proposed use case is probably at half capacity or
less. I am getting the impression that partitioning/formatting the drive for
the intended usage, and not the max capacity, is the way to go. Capacity isn't
an issue with this workload. I cannot fit enough drives into these servers to
get a tenth of the IOPS that even Tom's documents the ioDrive is capable of at
reduced performance levels.
The actual media is only good for a very limited number of write cycles. The
way that the drives get around to be reliable is to
constantly write to different areas. The more you have free, the less you have
to re-use, the longer the lifespan.
This is done by the drives wear levelling algorithms, not by using
partitioning utilities btw.
true, but if the drive is partitioned so that parts of it are never
written to by the OS, the drive knows that those parts don't contain data
and so can treat them as unallocated.
once the OS writes to a part of the drive, unless the OS issues a trim
command the drive can't know that the data there is worthless and can be
ignored, it has to try and preserve that data, which makes doing the wear
leveling harder and slower.
David Lang
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
