Date: Sat, 24 Aug 2002 05:00:38 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: 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: <20020824120038.GA4994@HAL9000.homeunix.com> In-Reply-To: <20020823212631.GA64644@hades.hell.gr> References: <31269226357BD211979E00A0C9866DAB02BB9988@rios.sitaranetworks.com> <20020823212631.GA64644@hades.hell.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020824120038.GA4994>