Date: Wed, 24 Jul 2013 10:27:35 -0500 From: Mark Felder <feld@freebsd.org> To: freebsd-geom@freebsd.org Subject: Re: TRIM or no TRIM? Message-ID: <1374679655.8934.9223372036856590361.535ACEE3@webmail.messagingengine.com> In-Reply-To: <BDD072A6EA1C4AE4A7E590BB094F7C87@multiplay.co.uk> References: <512DC7C043034F891F1012DA@Mail-PC.tdx.co.uk> <A34136B4528A476BB11F178D9469D7EB@multiplay.co.uk> <D6B2C9B94A5FD0E3111D83F7@Mail-PC.tdx.co.uk> <066EB1F973D44AAC951D4D47C577266F@multiplay.co.uk> <43FCB2933BDA7D36CA1719CD@Mail-PC.tdx.co.uk> <BDD072A6EA1C4AE4A7E590BB094F7C87@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 24, 2013, at 10:13, Steven Hartland wrote: > > gmirror may be another alternative that may correctly work with TRIM. > > For reference correctly setup MySQL performance on ZFS works well for > use. Of particular interest is some of our data is highly compressible > making ZFS compression of particular benefit for our work load. > There are known interactivity issues with ZFS compression, so keep that in mind. Also, you will want to make sure MySQL is on its own zfs filesystem and you may want to set primarycache=metadata so the database chooses what to keep in memory, not the filesystem. I ran a decent sized Postgres database of my own with compression and it was OK, but I didn't hit it very hard.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1374679655.8934.9223372036856590361.535ACEE3>