Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 02 Nov 2010 16:01:04 -0700
From:      Julian Elischer <julian@freebsd.org>
To:        "Mikhail T." <mi+thun@aldan.algebra.com>
Cc:        fs@freebsd.org
Subject:   Re: Using an SSD "disk" for /
Message-ID:  <4CD09830.3030400@freebsd.org>
In-Reply-To: <4CD0895A.5030402@aldan.algebra.com>
References:  <4CD04AEC.8040607@aldan.algebra.com> <4CD051A9.7090200@freebsd.org> <4CD0660E.2000102@aldan.algebra.com> <4CD06C4B.80100@freebsd.org> <4CD0895A.5030402@aldan.algebra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/2/10 2:57 PM, Mikhail T. wrote:
> 02.11.2010 15:53, Julian Elischer ΞΑΠΙΣΑΧ(ΜΑ):
>>> And? Do you use the TRIM-patches? Does performance stay high with 
>>> time -- with or without TRIM? Do you use FFS or some other 
>>> file-system? If FFS, are you relying on newfs' defaults?
>>
>> I'm not the person to talk to because I work fo rFusion-io (flash 
>> storage). I use our cards.. 

> Are you not at liberty to share the experiences with those cards? 
Our FreeBSD driver is limited a bit by the geom code but we get about 
500MB/sec
writes on the slower cards and about 800MB/sec on the faster cards, 
(per card).
with 800MB/sec read on both I think from memory (I don't have a slower 
one).
That's with larger sequential writes (32KB +) and reads.
With smaller ones the transaction overhead comes in and I have had 
trouble getting over
120,000 transactions per second with 512 byte records.
(slower machines would get smaller numbers).120,000 tps at 1/2 k each 
is only 60MB/sec.
So you see what you are doing can greatly change the performance you get.

  Our  FreeBSD driver doesn't support trim yet as we haven't had a lot 
of call for it.
but it will 'eventually' when we get the time.

Our cards are probably too expensive for personal use however.

On a more general direction however, regarding all SSDs and flash 
based devices
there are some characteristics that are just true across the board due 
to the
nature of flash memory.

On any flash drive, when the housekeeping kicks in, you find that the 
steady
state write speed drops because it has to spend some of it's internal 
resources
on housekeeping.

Trim is definitely not a requirement for a root partition. They don't 
move very fast.. :-/

> Even if you
> can't comment on quality, you can still talk about (un)importance of 
> TRIM-support
> as well as about fine-tuning FS-parameters, no?

Trim support is important in long-running situations where the
drive is going to use up it's 'reserve' capacity fairly quickly.
Because flash needs to be erased in large trunks, you need
to move stuff around fairly regularly "behind the back of the OS".
The more 'free' space the drive has to work with the more efficiently
it can do that and so the less of it's resources it has to use
for that purpose and the more resources are left for servicing
user/OS requests. If it can add the file-system's free space to
it's own spare space (thereby making the spare space
effectively larger) it can be a lot more efficient and thus
you get better performance. However if you are not pushing
the drive hard enough to make it use up its spare space, (continuous
writes for example) then trim will not have much effect. In
other words if the inbuilt housekeeping code can keep up with your write
requirements then trim will not make much of a difference..
For example if you have fast work for 15 seconds and then
let it sit idle for a couple of minutes, it SHOULD have done enough
housekeeping in that period so that when you start writing again,
it has enough spare space to quickly store your new data without
getting bottle-necked behind the housekeeper.  If you run out of your
'spare space' then  you depend on the speed of the housekeeper
to free up new space for you. Trim can also help by adding the trimmed
area to that 'spare space' number so it takes LONGER until you start
to depend on the housekeeper.

You can always increase the steady state speed of a flash drive by,
"never" writing to part of it.. e.g. newfs a smaller filesystem than the
drive. but if you "ever" write to the excess part you will need to either
use trim to reclaim that space or low-level reformat the drive. The space
beyond the filesystem will 'effectively' be added to the drive spare 
space until
it is written to.

I've seen this mentioned several times on various SSD lists and sites..

I can make no recomendations as I don't track them
>
> Thanks! Yours,
>
>    -mi
>




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