From owner-freebsd-questions Mon Aug 26 12: 1:50 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52C3B37B400; Mon, 26 Aug 2002 12:01:41 -0700 (PDT) Received: from apollo.sitaranetworks.com (apollo.sitaranetworks.com [199.103.141.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 542CE43E6A; Mon, 26 Aug 2002 12:01:40 -0700 (PDT) (envelope-from cptacek@sitaranetworks.com) Received: from rios.sitaranetworks.com (rios.sitaranetworks.com [199.103.141.78]) by apollo.sitaranetworks.com (8.10.2+Sun/8.9.3) with ESMTP id g7QJ1W629027; Mon, 26 Aug 2002 15:01:32 -0400 (EDT) Received: by rios.sitaranetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Aug 2002 15:02:19 -0400 Message-ID: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.com> From: Chris Ptacek To: "'David Schultz'" , Giorgos Keramidas Cc: Chris Ptacek , Carlos Carnero , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: RE: optimization changed from TIME to SPACE ?! Date: Mon, 26 Aug 2002 15:02:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I had a few questions... What actually causes the fragmentation to occur? I have tried just copying a small file over and over and this results in no fragmentation. This leads me to believe that the fragmentation is a result of simultainious open files or at least different file sizes. Also it seems that when we switch to SPACE optimizaiton is based on the % fragmentation based on the minfree setting. Can I change the minfree for the filesystem (I have a dedicated cache partition) to like 27% (8 is default) so that I am much less likely to hit the SPACE case? My question is other than reserving 27% of my disk space, will this cause any other problems or performance decreases? - Chris > -----Original Message----- > From: David Schultz [mailto:dschultz@uclink.Berkeley.EDU] > Sent: Saturday, August 24, 2002 5:01 AM > To: Giorgos Keramidas > Cc: Chris Ptacek; Carlos Carnero; freebsd-questions@FreeBSD.ORG; > freebsd-fs@FreeBSD.ORG > Subject: Re: optimization changed from TIME to SPACE ?! > > > Thus spake Giorgos Keramidas : > > Now that I have understood that this is an interesting interaction > > between the free space reserved aside from the total disk space and > > fragmentation, perhaps we can find some way to solve the problems > > SPACE optimizations might cause. > > > > What techniques would you use to reduce fragmentation? Changes in > > block/fragment ratio? Changes to the default fragment or > block size? > > > > Ideas anyone? > > If the filesystem contains many small files, e.g. a squid cache, a > smaller block size is probably appropriate. This should reduce > the number of fragments necessary without changing the block size > / fragment size ratio. With larger blocks, time optimization will > waste lots of space if you have lots of small files. > > In some cases, a smaller block size might be a bad idea even with > a small average file size. For example, if two-thirds of the > files in the filesystem suddenly required indirect blocks as a > result of lowering the block size, you would be shooting yourself > in the foot. > > I believe Softupdates mitigates some of the performance loss > associated with fragment copying because fragments can be > reallocated to full blocks if necessary before they are ever > written to disk. However, someone else should confirm this, since > I'm not sure about this point. > > By the way, you typically don't want to set the free space reserve > as low as 5%. It is not merely an administrative limit. When a > filesystem is low on space, it is impossible to allocate new data > in reasonably good positions on the disk; the limit prevents this > situation from occurring. (I believe we discussed this in another > thread a few months back.) If you set the reserve below 5%, FFS > assumes that you expect disk space to be very tight, so it > optimizes for space. As you pointed out, it also does this if > space *is* tight, i.e. the disk is within 2% of being full after > subtracting off the reserve. I suppose it's debatable whether > these policy decisions should be overridable, but most people just > give the filesystem enough room to breathe. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message