From owner-freebsd-questions@FreeBSD.ORG Thu Aug 28 15:50:08 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D3311065671 for ; Thu, 28 Aug 2008 15:50:08 +0000 (UTC) (envelope-from fbsdlists@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 270F68FC16 for ; Thu, 28 Aug 2008 15:50:08 +0000 (UTC) (envelope-from fbsdlists@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so237494yxb.13 for ; Thu, 28 Aug 2008 08:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=h8FcK32jCaIxwIIAJS51XReH33j0s78IMlgcOBggy9U=; b=ahCWtsx23jfphO04VWJLatb83zZZnJfeh22MXMMF0SxAozlnQTV9B9Uni1RprcSWha aSNWjNxZMHlUZ44tpBcQvH3RilxFodPpw51Mmpc6qOai6euVL4Pc7jhFsoJ+nbAgso2b Fng8GlcMAtFZE2KdkYM+LFzKjDgZv5b+PQk/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NwBZY7bcrYjJNcabZ0KwJTU2BhT+Cz3siKbQ3YaJf9OG0nWs/ZBOTZt/QHShDL+Uud bN0XHlwBQ8hJfLOgNKSECxr6xLcItX0GRu9h8hsIPFIbtgTyauqm/MPNSFxVVY4/3S4h gXGzq5ydVvUTdwCQk2Iq1QCTxakWq+GnlkQ5k= Received: by 10.114.192.17 with SMTP id p17mr1551530waf.29.1219938606671; Thu, 28 Aug 2008 08:50:06 -0700 (PDT) Received: by 10.114.193.16 with HTTP; Thu, 28 Aug 2008 08:50:05 -0700 (PDT) Message-ID: <54db43990808280850o29352e83me250d067f0c76717@mail.gmail.com> Date: Thu, 28 Aug 2008 11:50:05 -0400 From: "Bob Johnson" To: prad In-Reply-To: <20080827172946.5a1d4103@gom.home> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080827172946.5a1d4103@gom.home> Cc: "freebsd-questions @ freebsd. org" Subject: Re: defrag X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2008 15:50:08 -0000 On 8/27/08, prad wrote: > something that has puzzled me for years (but i've never got around to > asking) is how does *nix get away without regular defrag as with > windoze. > Essentially, the UFS file system (and its close relatives) is intentionally fragmented in a controlled way as the files are written, so that the effect of the fragmentation is limited. Files are written at sort-of-random locations all over the disk, rather than starting at one end and working toward the other, and there is a limit to how much sequential disk space a single file can occupy (a large file essentially gets broken up and stored as if it were a collection of smaller files). The result is that as long as there is a reasonable amount of empty disk space available, it will be possible to find space to store a new file efficiently. This is why the filesystem wants to have at least 8% empty space. If you have less than 8% empty space left on the filesystem, it switches from the speed optimizing mode that I just described to a mode that tries to pack things into the remaining space as efficiently as possible, at the cost of speed. FreeBSD also by default reserves some disk space for administrative use that is not available to normal users. One result of this scheme (and other issues) is that access time for large files suffers a bit (but not as much as it would if they were heavily fragmented). If you are setting up a volume mainly for storing large files, you can adjust some of the parameters (e.g. using tunefs(8)) so the filesystem will handle large files more efficiently, at the expense of wasting space on small files. > fsck is equivalent to scandisk, right? Pretty much. It looks for errors and tries to fix them. It does not attempt to defragment the disk. Unless the disk is almost full, defragmenting probably wouldn't improve things enough to matter. > > so when you delete files and start getting 'holes', how does *nix deal > with it? > The process of scattering files all over the disk intentionally leaves holes all over the disk (that's what I mean by controlled fragmentation). When you add and delete files, those holes get bigger and smaller, and merge or split apart, but until the disk gets very full, there should always be holes big enough to efficiently store new files. The difference between this and what happens in a FAT filesystem is that the process is designed so that there is a statistically high likelihood that the holes produced will be large enough to be used efficiently. > -- > In friendship, > prad I hope that helps. And as usual, if I got any of that wrong, someone please correct me. If I answer this question often enough, I will eventually get it right, then perhaps we can make it a FAQ ;-) - Bob