Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Jan 2009 13:54:50 +0100
From:      "Koen Smits" <kgysmits@gmail.com>
To:        "Andrew Snow" <andrew@modulus.org>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: FreeBSD, SSD's and partition alignment
Message-ID:  <b072dc420901070454j93b8237t1e67c16e94d00b6c@mail.gmail.com>
In-Reply-To: <4962A1D6.4040508@modulus.org>
References:  <b072dc420901051221t3cf398b0m1095946e9918c0f3@mail.gmail.com> <4962A1D6.4040508@modulus.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 6, 2009 at 01:12, Andrew Snow <andrew@modulus.org> wrote:

> I'd like to discuss this subject a bit if anyone's interested.
>> - partition alignment seems to be a real problem with some of today's
>> flash
>> and RAID media. I think people need to know one could easily increase
>> performance (and media wear!) as no one knows this problem exists.
>>
>
> Thanks for your interesting post!
>
> In my humble opinion, FreeBSD should not worry about this problem for the
> following reasons:
>
> 1. Performance for random write I/O still sucks even when the sector
> boundary is correct.  Doing something like untarring src or ports causes
> many small write I/Os, and it is simply a shortcoming of early generation
> flash controller technology that they erase and rewrite in large blocks.
>
> 2. This problem will go away when flash controller technology improves.
>  Intel SSDs have already demonstrated they can have great performance *and*
> a small erase block size, mitigating the issue completely.  This technology
> will trickle down to the cheaper flash SSDs over time.
>
>
> - Andrew
>

Sorry for the late reply. I've been busy.

I agree with point 1, if the controller is able to 'save up' small writes
and write this sequentially without making a mess out of it, this is
preferred. We will never completely remove the 'virtual layers' between the
OS and the storage medium itself and that is fine.

point 2 however, i disagree. It's time we dump the whole track/cylinder/head
thing. Even back in 1984 this was already outdated, lets just throw it
overboard! Let's assume that from FreeBSD 8 and onward, we just use GPT and
a partition offset of 1MB by default. Everybody would benefit, and no-one
would really have any problems with it, right? We would all benefit in my
opinion.

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b072dc420901070454j93b8237t1e67c16e94d00b6c>