From owner-freebsd-fs@FreeBSD.ORG Thu Jul 27 17:54:38 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 959EE16A4DE for ; Thu, 27 Jul 2006 17:54:38 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id DAAF543D46 for ; Thu, 27 Jul 2006 17:54:37 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 48337 invoked by uid 2001); 27 Jul 2006 17:54:36 -0000 Date: Thu, 27 Jul 2006 12:54:36 -0500 From: "Rick C. Petty" To: Dag-Erling Sm?rgrav Message-ID: <20060727175436.GA48057@megan.kiwi-computer.com> References: <44C6430D.1050506@centtech.com> <20060725175331.78302.qmail@web31806.mail.mud.yahoo.com> <20060725183410.GA32063@megan.kiwi-computer.com> <86lkqf1pum.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86lkqf1pum.fsf@xps.des.no> User-Agent: Mutt/1.4.2.1i Cc: freebsd-fs@freebsd.org Subject: Re: Advice for hacking on ufs/ffs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 17:54:38 -0000 On Thu, Jul 27, 2006 at 09:14:41AM +0200, Dag-Erling Sm?rgrav wrote: > "Rick C. Petty" writes: > > On Tue, Jul 25, 2006 at 10:53:31AM -0700, Shane Adams wrote: > > > I used dd to create 1G file. > > A faster way is: > > touch filename > > truncate -s 1g filename > > no, this will result in a fragmented image, which will hurt run-time > performance. Not necessarily. If you install a variant of windoze, the installer will format the disk first, writing zeros (and metadata) sequentially, and thus the allocation will not be fragmented. In the case of UFS newfs only the metadata will be written for each cylinder group and thus the logical blocks for all metadata will be contiguous. I wouldn't say this type of fragmenting absolutely *will* hurt performance but that it "may" hurt-- certainly tools like fsck would see a performance improvement. There are some performance advantages to reducing the seek time (in the underlying storage mechanism) for metadata operations, especially with larger disk caches. Without benchmarks, it's hard to say in general whether performance would be degraded due to the "random" allocation, if you also include FreeBSD's caching mechanisms. And UFS block allocation is quite predictable. But you are correct-- truncate(1) just changes the size of the file and doesn't allocate the underlying blocks. So there is a tendancy for it to become fragmented as blocks get allocated out of order. Also, I discovered that in my example, touch(1) isn't necessary... truncate(1) works on non-existent files. -- Rick C. Petty