Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 06 Jan 2014 23:07:17 +0100
From:      Miroslav Lachman <000.fbsd@quip.cz>
To:        Karl Pielorz <kpielorz_lst@tdx.co.uk>
Cc:        freebsd-geom@FreeBSD.org
Subject:   Re: Is TRIM working with gmirror?
Message-ID:  <52CB2915.7060602@quip.cz>
In-Reply-To: <18C59233568D3A475FF0D843@study64.tdx.co.uk>
References:  <52A90049.7050001@quip.cz> <18C59233568D3A475FF0D843@study64.tdx.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
Karl Pielorz wrote:
[...]
>> WARNING: /ssd_db: TRIM flag on fs but disk does not confirm that it
>> supports TRIM
>>
>> The filesystem is classic UFS2.
>>
>> Is TRIM supported throught gmirror, or not?
>
> I think 8.4 is way too old for this. I have a number of 9.2 boxes - and
> even on those, TRIM doesn't propagate through gmirror *yet* (at the
> time, which is a few months ago I seem to remember reading 'It should
> work soon' - but 9.2 doesn't appear to).
>
> You can use gstat to show if any calls to BIO_DELETE are being made - i.e.
>
> gstat -d
>
> On the systems here the 'd/s' (which afaik is 'BIO_DELETE/second')
> remains stubbornly at zero :(

Thank you for pointing me to gstat -d. d/s is really zero all the time.

> The flipside is with decent SSD's these days TRIM isn't quite so
> important... Some may even argue that *not* issuing heaps of BIO_DELETE
> on the I/O channel is actually faster - so long as the SSD has time to
> play catchup and isn't pegged all the time, I think they may be right :-)

The SSDs in question are holding /var/db/mysql with heavily used InnoDB 
tables (grow only ibdata file, few deletes of MyISAM tables) so maybe 
there are not much delete commands at all.

Thank you.

Miroslav Lachman



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