From owner-cvs-all  Thu May 10 19:27:55 2001
Delivered-To: cvs-all@freebsd.org
Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7EACE37B422; Thu, 10 May 2001 19:27:50 -0700 (PDT)
	(envelope-from mckusick@mckusick.com)
Received: from beastie.mckusick.com (localhost [127.0.0.1])
	by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id TAA14458;
	Thu, 10 May 2001 19:27:42 -0700 (PDT)
	(envelope-from mckusick@beastie.mckusick.com)
Message-Id: <200105110227.TAA14458@beastie.mckusick.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Subject: Re: cvs commit: src/sys/ufs/ffs fs.h softdep.h ffs_softdep.c ...
Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
In-Reply-To: Your message of "Tue, 08 May 2001 10:03:22 +0200."
             <57515.989309002@critter> 
Date: Thu, 10 May 2001 19:27:42 -0700
From: Kirk McKusick <mckusick@mckusick.com>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	To: Kirk McKusick <mckusick@FreeBSD.org>
	Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
	Subject: Re: cvs commit: src/sys/ufs/ffs fs.h softdep.h ...
	In-Reply-To: Your message of "Tue, 08 May 2001 00:42:20 PDT."
		     <200105080742.f487gKX83668@freefall.freebsd.org> 
	Date: Tue, 08 May 2001 10:03:22 +0200
	From: Poul-Henning Kamp <phk@critter.freebsd.dk>

	>  Note that this change does not solve the much harder
	>  problem of making this to-be-freed space available to applications
	>  that want it (thus on a nearly full filesystem, you may still
	>  encounter out-of-space conditions even though the free space will
	>  show up eventually). Hopefully this harder problem will be the
	>  subject of a future enhancement.

	Why not simply notice that free space will become available (by
	examining the counters, and sleep on something (lbolt ?) until
	either it does or it conclusively doesn't become available ?

	Also, wouldn't it make sense to allow less outstanding I/O for
	an almost full filesystem than for an empty one ?

At the point that you know that there are no blocks currently available,
you are deep in the allocation code holding a vnode locked. Space may
not show up for up to a minute. While you are waiting, a locking race
to the root can occur. While things will clear up eventually, the
perceived system performance is poor. Especially if it is happening
with any regularity. So, just waiting is not good enough, you have
to proactively clean up space. That can be hard since you cannot lock
any other vnodes (which can lead to deadlock). It is a solvable
problem, but it is not easy.

	Kirk

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message