Date: Mon, 26 Aug 2002 13:48:11 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Chris Ptacek <cptacek@sitaranetworks.com> Cc: Giorgos Keramidas <keramida@FreeBSD.ORG>, Carlos Carnero <zopewiz@yahoo.com>, freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: optimization changed from TIME to SPACE ?! Message-ID: <20020826204811.GA337@HAL9000.homeunix.com> In-Reply-To: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.com> References: <31269226357BD211979E00A0C9866DAB02BB998B@rios.sitaranetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Chris Ptacek <cptacek@sitaranetworks.com>: > 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? I'm not an expert on FFS, but hopefully someone will correct me if I have missed something. First of all, there are several kinds of fragmentation. One kind is where the blocks of a file are externally fragmented and scattered all over the disk, reducing performance. Some filesystems, such as FAT, make no effort to avoid this kind of fragmentation, which is why you need to run defrag every few weeks on them. UFS is good at avoiding this sort of fragmentation; unless the filesystem gets nearly full, it is usually able to place blocks for a given file close together. Internal fragmentation, on the other hand, occurs when a file doesn't take up all of the space in a block and the remaining space is wasted. For example, on a filesystem with an 8K block size, a 9K file requires two blocks. To mitigate this problem, FFS allows blocks to be split into up to 8 fragments. The fragments are used to store the tails of files that do not require full blocks, thus saving space. One problem with fragments is that dealing with them can be inefficient. If your 9K file grows to a 12K file, then to a 14K file, then to a 16K file, the filesystem may have to copy fragments around in order to fit all of the fragments for the end of the file into a single block. This is the kind of fragmentation fsck is telling you about. If you have FFS optimize for space, it will happily manage all of these fragments for you. If you tell it to optimize for time, FFS will still use fragments, but it won't bother to keep reallocating them when a file grows; instead, it will upgrade the file to a full block. The latter method is more efficient, but you lose a bit more space due to internal fragmentation. Thus, if FFS expects to run out of space, or if there are too many free fragments lying around, it will revert to space optimization until the situation improves. 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?20020826204811.GA337>