Date: Mon, 26 Aug 2002 15:02:18 -0400 From: Chris Ptacek <cptacek@sitaranetworks.com> To: "'David Schultz'" <dschultz@uclink.Berkeley.EDU>, Giorgos Keramidas <keramida@FreeBSD.ORG> Cc: Chris Ptacek <cptacek@sitaranetworks.com>, Carlos Carnero <zopewiz@yahoo.com>, freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: RE: optimization changed from TIME to SPACE ?! Message-ID: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.com>
next in thread | raw e-mail | index | archive | help
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 <keramida@FreeBSD.ORG>: > > 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31269226357BD211979E00A0C9866DAB02BB998B>