From owner-freebsd-fs@FreeBSD.ORG  Tue Aug 30 20:09:09 2011
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A570F106564A;
	Tue, 30 Aug 2011 20:09:09 +0000 (UTC)
	(envelope-from mckusick@mckusick.com)
Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235])
	by mx1.freebsd.org (Postfix) with ESMTP id 8682F8FC0C;
	Tue, 30 Aug 2011 20:09:09 +0000 (UTC)
Received: from chez.mckusick.com (localhost [127.0.0.1])
	by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id p7UK9CBQ085481;
	Tue, 30 Aug 2011 13:09:12 -0700 (PDT)
	(envelope-from mckusick@chez.mckusick.com)
Message-Id: <201108302009.p7UK9CBQ085481@chez.mckusick.com>
To: lev@freebsd.org
In-reply-to: <317753422.20110830231815@serebryakov.spb.ru> 
Date: Tue, 30 Aug 2011 13:09:12 -0700
From: Kirk McKusick <mckusick@mckusick.com>
X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY
	autolearn=failed version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com
Cc: freebsd-fs@freebsd.org
Subject: Re: Very inconsistent (read) speed on UFS2 
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Aug 2011 20:09:09 -0000

Now that you have defragmented your filesystem, we can factor that out
of the equation. What is left is the management of the memory used for
caching the files. I expect what is happening is that you are busily
reading along and run out of free memory in which to read. This triggers
a cleanup thread that churns through the memory pool to decide what
should be thrown out to make room. Your reading process is demanding
memory faster than the cleanup thread can produce it. The result is
that your read idles (e.g., appears to run slowly). It is random because
it depends on when you run out of memory.

The cleanup is complex because it has to deal with all of memory and
it wants to avoid a simple LRU which would cause the read of a large 
file to throw out a lot of things you would rather keep (like your 
window manager, browser, etc). Not sure what the best strategy is here.

	Kirk McKusick