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>