Date: Thu, 8 Jan 2009 16:31:51 +0100 From: "Koen Smits" <kgysmits@gmail.com> To: "Peter Schuller" <peter.schuller@infidyne.com> Cc: freebsd-fs@freebsd.org Subject: Re: FreeBSD, SSD's and partition alignment Message-ID: <b072dc420901080731y72ee505bp66690d431d176753@mail.gmail.com> In-Reply-To: <20090108132546.GA57786@hyperion.scode.org> References: <b072dc420901051221t3cf398b0m1095946e9918c0f3@mail.gmail.com> <4962A1D6.4040508@modulus.org> <b072dc420901070454j93b8237t1e67c16e94d00b6c@mail.gmail.com> <20090108132546.GA57786@hyperion.scode.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I have not tested this to an extent that I can be sure this is the way it works. Sorry. On Thu, Jan 8, 2009 at 14:25, Peter Schuller <peter.schuller@infidyne.com>wrote: > > Note that even the Intel X25-M series seem to slow down in random write > > speed when the complete disk is filled and there are no cells left that > the > > controller knows are free. Most benchmarks out there are run on an empty > > Intel SSD. When you rerun that test several times, it'll slowly settle on > a > > much lower random write speed. > > My understanding is that the performance drop should only come from > *sustained* high write iops; i.e., when you effectively exhaust the > free space necessary to perform the writes sequentially but > temporarily. But on the other hand if you are only bursting, I was > under the impression these guys did background re-writing such that no > permanent performance drop need be expected. > > Is this not the case for the X25-M or others? > > -- > / Peter Schuller > > PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' > Key retrieval: Send an E-Mail to getpgpkey@scode.org > E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b072dc420901080731y72ee505bp66690d431d176753>