From owner-freebsd-stable@FreeBSD.ORG Tue Jan 26 18:10:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA9561065750 for ; Tue, 26 Jan 2010 18:10:51 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id A9AB28FC0C for ; Tue, 26 Jan 2010 18:10:50 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id o0QI0R01014634; Tue, 26 Jan 2010 10:00:27 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id o0QI0QHA014631; Tue, 26 Jan 2010 10:00:26 -0800 (PST) Date: Tue, 26 Jan 2010 10:00:26 -0800 (PST) From: Matthew Dillon Message-Id: <201001261800.o0QI0QHA014631@apollo.backplane.com> To: Aragon Gouveia References: <4B54C100.9080906@mail.zedat.fu-berlin.de> <4B5CCBDA.3090403@phat.za.net> Cc: freebsd-stable@freebsd.org Subject: Re: immense delayed write to file system (ZFS and UFS2), performance issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:10:51 -0000 :I'm experiencing the same thing, except in my case it's most noticeable :when writing to a USB flash drive with a FAT32 filesystem. It slows the :entire system down, even if the data being written is coming from cache :or a memory file system. : :I don't know if it's related. I'm running 8-STABLE from about 4 December. : :Regards, :Aragon I don't know re: the main thread but in regards to writing to a USB flash drive interfering with other operations the most likely cause is that the buffer cache fills up with dirty buffers destined for the (slow) USB drive. This causes other unrelated drive subsystems to block on the buffer cache. There are no easy answers. A poor-man's solution would be to limit dirty buffers in the buffer cache to 80% of the nominal dirty maximum on a per-mount basis so no single mount can kill the buffer cache. (One can't just cut-up the buffer cache as that would leave too few buffers available for each mount to operate efficiently). A per-mount minimum buffer guarantee would also help smooth things out but the value would have to be small (comprise no more than 20% of the buffer cache in aggregate). In the case of UFS the write-behind code is asynchronous, so even though UFS wants to flush the buffers out all that happens in reality when writing to slow media is that the dirty buffers wind up on the I/O queue (which is actually worse then leaving them B_DELWRI in the buffer cache because now the VM pages are all soft-busied). -Matt Matthew Dillon