Skip site navigation (1)Skip section navigation (2)
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-questions" 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>