From owner-cvs-all Tue May 8 1: 3:39 2001 Delivered-To: cvs-all@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id B72E637B423; Tue, 8 May 2001 01:03:34 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4883M857517; Tue, 8 May 2001 10:03:22 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Kirk McKusick Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs fs.h softdep.h ffs_softdep.c ffs_softdep_stub.c ffs_inode.c ffs_vfsops.c src/sys/ufs/ufs ufs_extern.h inode.h ufs_inode.c 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 Message-ID: <57515.989309002@critter> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message