On Tue, 20 Apr 2010 16:22:32 -0500 Marco Peereboom <sl...@peereboom.us>
wrote:
> On Tue, Apr 20, 2010 at 03:01:58PM -0500, Marco Peereboom wrote:
> > On Tue, Apr 20, 2010 at 03:48:23PM -0400, Ted Unangst wrote:
> > > On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom
> > > <sl...@peereboom.us> wrote:
> > > >>> And no, TRIM isn't supported.
> > >
> > > >> The problem is that we're copying the entire disk, so, as far
> > > >> as the disk (i.e., SSDs) is aware, that disk is 100% full--
> > > >> all blocks are marked as used even if they're empty. If I
> > > >> understand correctly, how the controller handles block
> > > >> reallocation in this scenario depends how it is
> > >
> > > > You are. The whole not write so often is really really really
> > > > uninteresting.
> > >
> > > It's not about writing too often, it's about the performance hit
> > > doing a read/modify/write when there's no free blocks. Like the
> > > 4k sector problem, but potentially even worse.
> > >
> > > On the other hand, it depends on how much writing your server
> > > will do in service. If you aren't writing large files, you won't
> > > notice much difference, and the benefit of ultra fast random
> > > access is more than worth it.
> >
> > I am 100% unconvinced.
>
> I *was* 100% unconvinced. I am much better educated now. Yes this
> could be neat :-)
>
Heck, that didn't take long. ;)
The impact of read/modify/write can be significant on SSD's, and
performance of these devices degrades over time/use. The percent of the
over-time degradation attributed to the read/modify/write issue is
typically unknown, so TRIM just helps but doesn't solve the whole
enchilada.
Unfortunately, just getting TRIM support implemented in the low levels
doesn't solve the entire problem, you also have to teach the
filesystems to use it.
At this point, even if TRIM was supported, using currently available
SSD's on a mail server with tons of small writes means you're doomed to
constantly baby sitting the performance of the system since it will
degrade. You might be better off in the long run using multiple
rotating disks that are half as fast, and half the price, but won't
degrade.
jcr
--
The OpenBSD Journal - http://www.undeadly.org
