From owner-freebsd-questions@FreeBSD.ORG Wed Nov 22 07:45:47 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EC2B16A4A7 for ; Wed, 22 Nov 2006 07:45:47 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (pool-71-117-237-189.ptldor.fios.verizon.net [71.117.237.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FCA343D6D for ; Wed, 22 Nov 2006 07:45:17 +0000 (GMT) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (localhost.home.localnet [127.0.0.1]) by schitzo.solgatos.com (8.13.7/8.13.6) with ESMTP id kAM7jh2Q025149 for ; Tue, 21 Nov 2006 23:45:43 -0800 Received: from sopwith.solgatos.com (uucp@localhost) by schitzo.solgatos.com (8.13.7/8.13.4/Submit) with UUCP id kAM7jhCA025146 for freebsd-questions@freebsd.org; Tue, 21 Nov 2006 23:45:43 -0800 Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id HAA18428; Wed, 22 Nov 2006 07:12:38 GMT Message-Id: <200611220712.HAA18428@sopwith.solgatos.com> To: freebsd-questions@freebsd.org In-reply-to: Your message of "Mon, 20 Nov 2006 11:19:52 EST." <20061120111952.4213dacb.wmoran@collaborativefusion.com> Date: Tue, 21 Nov 2006 23:12:38 +0000 From: Dieter Subject: processes not getting fair share of available disk I/O (was: Re: TCP parameters and interpreting tcpdump output ) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2006 07:45:47 -0000 > I'm surprised that you're seeing that much of a "hang". Even if the disks > are busy, the system should slow down all disk processes equally, so no > one process "blocks", but they're all a little slower. I collected a bit of data: While copying a large file from disk1 to disk2, time ls on a small directory on disk3 (not cached in memory) real 0m0.032s user 0m0.000s sys 0m0.003s time ls on a small directory on disk2 real 4m51.911s user 0m0.000s sys 0m0.002s I expect access to a busy disk to take longer, but 5 minutes is a bit much. And that's the root directory of the filesystem, it didn't have to follow a long chain of directories to get there. Sometimes I see long delays when accessing disk3, but it is behaving at the moment.