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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[email protected]"
