On Thu, 14 Apr 2011 11:46:12 +0200, Henry C. wrote:
On Thu, April 14, 2011 11:30, Leonardo Francalanci wrote:
have a look at
http://postgresql.1045698.n5.nabble.com/Intel-SSDs-that-may-not-suck-td426826
1.html
It looks like those are "safe" to use with a db, and aren't that
expensive.
The new SSDs look great. From our experience, we trust SSDs (even
MLC) far
more than mechanical hard drives.
I believe this perception that SSDs are less "safe" than
failure-prone
mechanical hard drives will eventually change.
In the meantime, we've embraced them and the advantages are
compelling.
h
One thing you should care about is such called write endurance - number
of writes to one memory region before it will be destroyed - if your SSD
driver do not have transparent allocation, then you may destroy it
really fast, because write of each "block" will be in same memory
segment, clog/xlog may be failed with 10k-100k writes. But if your SSD
has transparent allocation, then internal controller will count your
writes to given memory cell, and when lifetime of this cell will be at
the end, it will "associate" block with different cell. With transparent
allocation, You may sometimes do not fear if system uses journaling, you
store logs there on any kind of often updatable data. You may calculate
life time of your SSD with:
WritesToDestroyCells = "write_endurance" * "disk_size"
AvgLifeTime = WritesToDestroyCells / writes_per_sec
Those are high numbers, even with simply disks as 10.000 * 60GB, means
you need to send 600TB of data to one SSD (not completely true, as you
can't send one byte, but full blocks) . Ofc, In order to extend life
time of SSD you should provide file systems cache, or SSD with cache, as
well turn off FS journaling.
Regards,
Radek
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
