The whole "SSD fails after X number of writes" thing is pretty much a myth
now that most drives implement pretty aggressive write leveling. These
modern drives introduce a mapping layer between the physical disk locations
and the location written to by the OS. This means that writing to "KB 4242"
o
We have been running builds on the same SSDs, doing intensive logging, ... for
three years now.
None deteriorated.
Builds are mainly scrap & write thousands of small files plus a few big ones
(the targets).
Write speed makes a huge difference for this kind of task.
Aws allows to get VMs with
I'm under the impression that, because of the hard limit on writes, OSes
often already cache writes to SSDs, further limiting their usefulness in
this kind of application.
On Friday, March 6, 2015 at 4:10:54 PM UTC-5, Fluid Dynamics wrote:
>
> On Friday, March 6, 2015 at 3:16:09 PM UTC-5, Michae
On Friday, March 6, 2015 at 3:16:09 PM UTC-5, Michael Blume wrote:
>
> Possibly stupid question: can you just pretend you have more memory than
> you do and let the operating system do the heavy lifting?
>
As in, put the swap partition on the SSD and jack up the virtual memory in
the OS config?
You could build something on top memory mapped files. I did this to solve
similar requirements with good effect.
On 6 Mar 2015 18:55, "JPatrick Davenport" wrote:
> Hello,
> I'm been thinking about an idea for a cache layer. It's driven by two
> trends.
>
> Most caches are in memory. They might ha
Possibly stupid question: can you just pretend you have more memory than
you do and let the operating system do the heavy lifting?
On Fri, Mar 6, 2015, 10:54 AM JPatrick Davenport wrote:
> Hello,
> I'm been thinking about an idea for a cache layer. It's driven by two
> trends.
>
> Most caches ar
