From owner-freebsd-current Sat Oct 9 14:29:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 8794714E16; Sat, 9 Oct 1999 14:29:37 -0700 (PDT) (envelope-from dima@tejblum.pp.ru) Received: (from uucp@localhost) by arc.hq.cti.ru (8.9.3/8.9.3) with UUCP id BAA64032; Sun, 10 Oct 1999 01:29:31 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Received: from tejblum.pp.ru (localhost [127.0.0.1]) by tejblum.pp.ru (8.9.3/8.9.3) with ESMTP id BAA04136; Sun, 10 Oct 1999 01:34:14 +0400 (MSD) (envelope-from dima@tejblum.pp.ru) Message-Id: <199910092134.BAA04136@tejblum.pp.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: "David Schwartz" Cc: obrien@FreeBSD.ORG, freebsd-current@FreeBSD.ORG From: Dmitrij Tejblum Subject: Re: {a}sync updates (was Re: make install trick) In-reply-to: Your message of "Fri, 08 Oct 1999 10:20:03 PDT." <000d01bf11b1$5bfca1f0$021d85d1@youwant.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Oct 1999 01:34:13 +0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David Schwartz" wrote: > We're talking about the special case of small root partitions, such that > softupdates inability to make empty space available quickly can make the > difference between a major operation's success or failure. > > This is almost impossible on a 1.8Gb root partition. [sorry, cannot resist...] Once upon a time, a month or so ago, there were ~30G of free space on our 130G filesystem (with softupdates). An important application that was going to create a ~35G file was running. It already written out 1G or so. My colleague called me and sayed: "I removed a 10G of files TWO HOURS ago and the space didn't free up yet!!! The free space isn't going to appear!!! What do we do now???" Well, after I stopped the application with kill -STOP, and temporary killed off another I/O consuming program, the free space started to appear and after several minutes there were >40G of free space. I think that the problem in this particular case was inability of the syncer to run as fast as it supposed to. It is assummed that syncer fsync 1/30 of all files and process the softupdates worklist every second. If there are several I/O bound processes running, the syncer will not have enough I/O bandwidth to do this job in the required speed. Perhaps running several syncer processes could help. (OTOH, the machine in question is running a quite old version of FreeBSD-CURRENT, it is possible things are already better. I don't see serious changes in softupdates code from that moment, tough. It is also possible that the machine is mistuned in some way, but I don't know how :-() Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message