From owner-freebsd-questions@FreeBSD.ORG Wed May 12 13:46:05 2010 Return-Path: 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 53E7E106566C for ; Wed, 12 May 2010 13:46:05 +0000 (UTC) (envelope-from ahamiltonwright@mta.ca) Received: from smtpx.mta.ca (smtpx.mta.ca [138.73.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 244B38FC15 for ; Wed, 12 May 2010 13:46:05 +0000 (UTC) Received: from [138.73.29.51] (port=49209 helo=qemg.org) by smtpx.mta.ca with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1OCCGB-0003Sl-7L for freebsd-questions@freebsd.org; Wed, 12 May 2010 10:46:03 -0300 Date: Wed, 12 May 2010 10:46:03 -0300 (ADT) From: "A. Wright" To: freebsd-questions@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: ahamiltonwright@mta.ca Subject: Long I/O pauses on same mass storage 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, 12 May 2010 13:46:05 -0000 I have recently upgraded my system to 8.0, and in the course of doing so, have migrated most filesystems onto a new drive. I have noticed, since the upgrade, several instances where a very long pause occurs during which time one or more process is in uninterruptible device wait. This seems to most commonly happen when both reading and writing tasks are active -- I am unsure whether reads writes must be in the same partition, or whether two partitions on the same drive are sufficient. These pauses are quite long, on the order of 10 seconds or more, and happen during tasks that ran quite happily before the upgrade (example: if doing a lengthy compile, or subversion update, then opening an editor will "hang" while attempting to open the executable). As I am in the situation of switching from 7.2->8.0 and at the same time using a new drive, I would like to eliminate one of these from the equation first. Before I will be able to move on to chasing down the manufacturer if the drive is faulty, I will need some good data. While I will run some further tests here, I thought I would ask: Is anyone else seeing poor disk I/O scheduling or locking behaviour in 8.0? Is anyone aware of any of the filesytem changes that have occurred since 7.2 that may explain this? Does anyone have any thoughts on how to conclusively prove that the drive is at fault? I have not seen any errors logged to dmesg. Thanks, Andrew.