From nobody@FreeBSD.org  Mon Sep 21 22:27:53 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 6867B106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 21 Sep 2009 22:27:53 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 579038FC0A
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 21 Sep 2009 22:27:53 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n8LMRqJa055243
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 21 Sep 2009 22:27:52 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n8LMRqkE055242;
	Mon, 21 Sep 2009 22:27:52 GMT
	(envelope-from nobody)
Message-Id: <200909212227.n8LMRqkE055242@www.freebsd.org>
Date: Mon, 21 Sep 2009 22:27:52 GMT
From: Nathaniel Filardo <nwf@cs.jhu.edu>
To: freebsd-gnats-submit@FreeBSD.org
Subject: zpool scrub makes system unbearably slow
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         139039
>Category:       kern
>Synopsis:       [zfs] zpool scrub makes system unbearably slow
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pjd
>State:          suspended
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 21 22:30:03 UTC 2009
>Closed-Date:    
>Last-Modified:  Sun Sep 27 18:48:39 UTC 2009
>Originator:     Nathaniel Filardo
>Release:        9.0-CURRENT
>Organization:
>Environment:
FreeBSD hydra.priv.oc.ietfng.org 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Sun Sep 13 10:12:17 EDT 2009     root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN  sparc64

>Description:
Even with the sysctl "vfs.zfs.scrub_limit" given value 2, scrubbing my 8-disk array is an exercise in frustration.  The system remains online, and will eventually respond to events, but it's incredibly lagged, even when the events do not directly relate to the controller card and disks making up the array.

The array is 4x320G and 4x750G SATA disks on a
mpt0: <LSILogic SAS/SATA Adapter> port 0x300-0x3ff mem 0x100000-0x103fff,0x130000-0x13ffff at device 1.0 on pci3
mpt0: MPI Version=1.5.10.0

For (I assume unrelated) stability reasons (see pr kern/117688), I have had to run "camcontrol tags $DISK -N 16" for each of the disks in the array.

WITNESS and INVARIANTS are both turned on; I've not tried with them off; should I?
>How-To-Repeat:
Reliably triggered by issuing a scrub request.
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue Sep 22 04:16:07 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=139039 
State-Changed-From-To: open->feedback 
State-Changed-By: pjd 
State-Changed-When: ptk 25 wrz 2009 18:27:48 UTC 
State-Changed-Why:  
Could you tell which threads are consuming most CPU time? 
Pasting first few lines from 'top -SH' should be enough. 


Responsible-Changed-From-To: freebsd-fs->pjd 
Responsible-Changed-By: pjd 
Responsible-Changed-When: ptk 25 wrz 2009 18:27:48 UTC 
Responsible-Changed-Why:  
I'll take this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=139039 
State-Changed-From-To: feedback->suspended 
State-Changed-By: pjd 
State-Changed-When: ndz 27 wrz 2009 18:47:44 UTC 
State-Changed-Why:  
I cannot reproduce the problem on my test machine, it can be related to 
the mpt(4) driver and not ZFS, hard to say. Suspend PR for now. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=139039 
>Unformatted:
