From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 5 22:04:56 2003 Return-Path: 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 D780516A4BF; Fri, 5 Sep 2003 22:04:56 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82B3243F85; Fri, 5 Sep 2003 22:04:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldthf.dialup.mindspring.com ([209.86.246.47] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19vVFR-0002RD-00; Fri, 05 Sep 2003 22:04:34 -0700 Message-ID: <3F596AAB.843C86F5@mindspring.com> Date: Fri, 05 Sep 2003 22:03:39 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Gilbert References: <3F5647F3.5080502@he.iki.fi> <16216.36410.889440.499438@canoe.velocet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e0ec236727729bd695c827fea927f3d7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Poul-Henning Kamp cc: Petri Helenius cc: Max Clark cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: Dan Nelson cc: freebsd-questions@freebsd.org Subject: Re: 20TB Storage System X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2003 05:04:57 -0000 David Gilbert wrote: > >>>>> "Poul-Henning" == Poul-Henning Kamp writes: > Poul-Henning> I am not sure I would advocate 64k blocks yet. > Poul-Henning> I tend to stick with 32k block, 4k fragment myself. > > That reminds me... has anyone thought of designing the system to have > more than 8 frags per block? Increasingly, for large file > performance, we're pushing up the block size dramatically. This is > with the assumption that large disks will contain large files. My assumptions on the previous two statements by Poul are: 1) You cannot trust that a short will be treated as an unsigned 16 bit value in all cases, so values that are between 32768 and 65535 may be treated incorrectly. 2) A fully populate block bitmap byte, which means a divide by 8, is necessary to avoid potential division errors. In other words, he's afraid that the sign bit and/or the block size bitmap used by frags may be treated incorrectly. I have to agree with both those observations. A number of people have, historically, reported issues with a divisor other than 8, and the worry about the sign bit is common sense, given the many historical issues faced by other OS's when it comes to 64K block sizes. -- Terry