From owner-freebsd-fs@FreeBSD.ORG Wed Sep 26 17:10:56 2007 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4942F16A41B for ; Wed, 26 Sep 2007 17:10:56 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id E191E13C447 for ; Wed, 26 Sep 2007 17:10:55 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 41633 invoked by uid 2001); 26 Sep 2007 17:10:54 -0000 Date: Wed, 26 Sep 2007 12:10:54 -0500 From: "Rick C. Petty" To: Bruce Evans Message-ID: <20070926171054.GA41567@keira.kiwi-computer.com> References: <46F3A64C.4090507@fluffles.net> <46F3B520.1070708@FreeBSD.org> <20070926030358.GA34186@keira.kiwi-computer.com> <20070926171239.E58990@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070926171239.E58990@delplex.bde.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-fs@FreeBSD.org Subject: Re: Writing contigiously to UFS2? 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: Wed, 26 Sep 2007 17:10:56 -0000 On Wed, Sep 26, 2007 at 05:59:24PM +1000, Bruce Evans wrote: > On Tue, 25 Sep 2007, Rick C. Petty wrote: > > That's insignificantly more. Even doubling the size wouldn't make much > difference. I see differences of at most 25% going the other way and Some would say that 25% difference is significant. Obviously you disagree. > 4K blocks, 512-frags -e 512 (broken default): 40MB/S > 4K blocks, 512-frags -e 1024 (broken default): 44MB/S > 4K blocks, 512-frags -e 2048 (best), kernel fixes: 47MB/S > 4K blocks, 512-frags -e 8192 (try too hard), kernel fixes > (kernel fixes are not complete enough to handle this case; > defaults and -e values which are < the cg size work best except > possibly when the fixes are complete): 45MB/S > 16K blocks, 2K-frags -e 2K (broken default): 50MB/S > 16K blocks, 2K-frags -e 4K (fixed default): 50.5MB/S > 16K blocks, 2K-frags -e 8K (best): 51.5MB/S > 16K blocks, 2K-frags -e 64K (try too hard): < 51MB/S again Are you talking about throughputs now? I was just talking about space. Time and space are usually mutually-exclusive optimizations. > >Here might be an interesting experiment to try. Write a new version of > >/usr/src/sbin/newfs/mkfs.c that doesn't have the restriction that the free > >fragment bitmap resides in one block. I'm not 100% sure if the FFS code > >would handle it properly, but in theory it should work (the offsets are > >stored in the superblocks). This is the biggest restriction on the CG > >size. You should be able to create 2-4 CGs to span each of your 1TB > >drives without increasing the block size and thus minimum allocation unit. > > In theory it won't work. From fs.h: > > %%% > /* > * The size of a cylinder group is calculated by CGSIZE. The maximum size > * is limited by the fact that cylinder groups are at most one block. > * Its size is derived from the size of the maps maintained in the > * cylinder group and the (struct cg) size. > */ > %%% Debug code, not comments! :-P > Only offsets to the inode blocks, etc. are stored in the superblock. Yes, the offset to the cylinder group block and the offset to the inode block are in the superblock (struct fs). It wouldn't be too difficult to tweak the ffs code to read in CGs larger than one block, by checking the difference between fs_iblkno and fs_cblkno. I'm saying it's theoretically possible, although it will require tweaks in ffs code. Again, I think it's worth investigating, especially if you believe there are performance penalties for having block sizes greater than the kernel buffer size. -- Rick C. Petty