From owner-freebsd-questions@FreeBSD.ORG Thu Mar 1 22:21:59 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04C2E16A411 for ; Thu, 1 Mar 2007 22:21:59 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id B6D4A13C4AA for ; Thu, 1 Mar 2007 22:21:58 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Thu, 01 Mar 2007 17:21:58 -0500 id 00056436.45E75206.0000FAB5 Date: Thu, 1 Mar 2007 17:21:57 -0500 From: Bill Moran To: Ivan Voras Message-Id: <20070301172157.8fc10842.wmoran@collaborativefusion.com> In-Reply-To: References: <539c60b90703010849x33dd4bbbt8f6ca6aa0c8e83a0@mail.gmail.com> <20070301165055.638b0a06.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.9; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 01 Mar 2007 22:21:59 -0000 In response to Ivan Voras : > Bill Moran wrote: > > In response to Ivan Voras : > > >> 352462 files, 2525857 used, 875044 free (115156 frags, 94986 blocks, > >> 3.4% fragmentation) > > > > > Just to reiterate: > > "Fragmentation" on a Windows filesystem is _not_ the same as "fragmentation" > > on a unix file system. They are not comparable numbers, and do not mean > > the same thing. The only way to avoid fragmentation on a unix file system > > is to make every file you create equal to a multiple of the block size. > > Ok, my point was that 3.4% is a low number for a long used system, but, > for education sake, what is the difference between Windows' > "fragmentation" and Unix's "fragmentation"? > > I believe that a "fragmented file" in common usage refers to a file > which is not stored continuously on the drive - i.e. it occupies more > than one continuous region. How is UFS fragmentation different than > fragmentation on other kinds of file systems? That common usage refers to Windows filesystems. In unix filesystems, fragmentation refers to the number of blocks that have been broken down in to fragments to either hold files smaller than a block, or (as you mentioned) use the space at the end of a file that doesn't fit exactly in a block. > UFS has cylinder groups, blocks and block fragments. Obviously, a file > larger than a cylinder group will get fragmented to spill over to > another cylinder group. Block fragments only occur at the end of files. Yes, and UFS _intentionally_ creates what Windows users would call "fragmentation" There's no way I know of to measure this, however. The key to understanding this is that not all fragmentation is bad. Typically, files are accessed in chunks. Your OS seldom grabs an entire 50M file all at once -- it grabs (perhaps) 16 blocks worth, then sends it to the requesting program, then grabs another 16 blocks worth, etc, etc. The time between grabbing a chunk is enough that allowing the heads time to reposition to a difference cylinder group doesn't cause a significant performance problem. As a result, the OS _intentionally_ switches to a different cylinder group after a certain number of blocks have been written (this is tunable with tunefs). The result is that a large file will typically be strewn about the disk. But this also makes it _easy_ for the filesystem to avoid causing the type of fragmentation that _does_ degrade performance. For example, when the first block is on track 10, then the next block is on track 20, then we're back to track 10 again, then over to track 35 ... etc, etc Keep in mind, that in the previous 3 paragraphs, I was using the "Windows" definition of "fragmentation." -- Bill Moran Collaborative Fusion Inc.