From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 10 10:02:03 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B339616A41F for ; Wed, 10 Aug 2005 10:02:03 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC4643D53 for ; Wed, 10 Aug 2005 10:02:02 +0000 (GMT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.13.3/8.13.3) with ESMTP id j7AA21pO022078 for ; Wed, 10 Aug 2005 14:02:01 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 10 Aug 2005 14:02:01 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-hackers@FreeBSD.org Message-ID: <20050810135713.K18426@woozle.rinet.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (woozle.rinet.ru [0.0.0.0]); Wed, 10 Aug 2005 14:02:01 +0400 (MSD) Cc: Subject: ffs_alloc.c: minfree Q X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2005 10:02:03 -0000 Colleagues, from ffs_alloc.c: case FS_OPTSPACE: /* * Allocate an exact sized fragment. Although this makes * best use of space, we will waste time relocating it if * the file continues to grow. If the fragmentation is * less than half of the minimum free reserve, we choose * to begin optimizing for time. */ request = nsize; if (fs->fs_minfree <= 5 || --->>> ~~~~~~~~~~~~~~~~~~~~~~ fs->fs_cstotal.cs_nffree > (off_t)fs->fs_dsize * fs->fs_minfree / (2 * 100)) break; log(LOG_NOTICE, "%s: optimization changed from SPACE to TIME\n", fs->fs_fsmnt); fs->fs_optim = FS_OPTTIME; break; For contemporary situation, where total size of file system can grow to hundreds of Gs or even several Ts, 8% of space seems too high. Maybe this algorithm should be slightly adjusted (I'm thinking of logarithmic scale depending on file system size)? Any (contemporary) references would be highly appreciated. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------