Trim on gmirrored SSDs is slow and results in inresponsive system
Steven Hartland
killing at multiplay.co.uk
Wed Mar 4 14:38:29 UTC 2015
On 04/03/2015 14:19, Robert Schulze wrote:
> Hi,
>
> Am 04.03.2015 um 14:25 schrieb Steven Hartland:
>> Do you have one disk which has really slow TRIM?
>>
> please note, it does not depend on the disk, it is related to gmirror.
Yes but gmirror will wait for all disks to complete the delete before
the top level delete is marked as complete, so if you have an issue with
one of the underlying devices, be that cabling issue or disk on the way
out, this could be your issue.
>> Also how does gstat -d -p compare between gmirror and none gmirror
>> installs on the same machine?
> Deleting on a non-mirrored UFS does not influence the system, because
> the BIO_DELETE calls are processed extremely fast (~ 1 sec with 1GB
> file), with a high number of d/s (~ 100k).
Can you get snapshot of both in action please
>
>> Do you see high kernel CPU when the deletes are happening?
> no. Here are the top system processes after deleting a 5GB file:
>
> 0:40 144.87% cam
> 0:22 77.59% g_mirror var
> 0:14 62.79% bufdaemon
> 0:14 0.88% intr
> 0:13 0.59% geom
> 0:01 0.00% rand_harvestq
> 0:00 0.00% kernel
144% in cam is very high and g_mirror is high too.
What OS build is this?
http://svnweb.freebsd.org/changeset/base/267118 could well be the cause of high CAM CPU, this was one of main reasons why the original bypass or sorting was added.
Regards
Steve
More information about the freebsd-geom
mailing list