From owner-freebsd-questions@FreeBSD.ORG Sat Mar 3 14:19:29 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 C929B16A400 for ; Sat, 3 Mar 2007 14:19:29 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx1.netclusive.de (mx1.netclusive.de [89.110.132.131]) by mx1.freebsd.org (Postfix) with ESMTP id 8E13013C442 for ; Sat, 3 Mar 2007 14:19:29 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fdd20.f.ppp-pool.de [195.4.221.32]) by mx1.netclusive.de (Postfix) with ESMTP id DE026DE8044 for ; Sat, 3 Mar 2007 15:19:27 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 78CFD15213; Sat, 3 Mar 2007 15:19:26 +0100 (CET) To: freebsd-questions@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.questions Date: Sat, 3 Mar 2007 15:19:26 +0100 (CET) Organization: Convenimus Projekt Lines: 30 Message-ID: References: <539c60b90703010849x33dd4bbbt8f6ca6aa0c8e83a0@mail.gmail.com> <20070301165055.638b0a06.wmoran@collaborativefusion.com> <20070301172157.8fc10842.wmoran@collaborativefusion.com> NNTP-Posting-Host: garfield.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1172931566 99267 192.168.100.11 (3 Mar 2007 14:19:26 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sat, 3 Mar 2007 14:19:26 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD) 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: Sat, 03 Mar 2007 14:19:29 -0000 On Thu, 1 Mar 2007 17:21:57 -0500 Bill Moran wrote: > 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 Fragmentation *this* bad doesn't happen on MS systems either. Although the systems are much more in danger of creating a big mess on the drive, there is a certain method included to reduce this, like only allowing the track numbers to either rise or fall (possibly per file access) but not back and forth over the drive. I can remember experimenting on my Commodore 64 (can anyone remember that ol' thing?) and the floppy drive. I stored a file all over the disc, one sector per track. The idea was to find out how much time it actually took to load a file "fragmented" like this - and made a really cool loading sound as well, especially if you had a floppy speeder like dolphin DOS. :-) I wanted to actually cause the drive to go from track 1 to 40 and then back again while loading a single file. But that didn't work. So if I started on track a and I am now on track c, then jumping to track b (with a