From owner-freebsd-arch@FreeBSD.ORG Fri Apr 9 08:18:41 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43256106566B for ; Fri, 9 Apr 2010 08:18:41 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 889E38FC15 for ; Fri, 9 Apr 2010 08:18:40 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA13817 for ; Fri, 09 Apr 2010 11:18:39 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O09QE-0004fI-NE for arch@freebsd.org; Fri, 09 Apr 2010 11:18:38 +0300 Message-ID: <4BBEE2DD.3090409@freebsd.org> Date: Fri, 09 Apr 2010 11:18:37 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: arch@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: (in)appropriate uses for MAXBSIZE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 08:18:41 -0000 As you know MAXBSIZE is currently defined to 64K (seems to a popular value for constants). There is the following comment for this parameter and its value: MAXBSIZE - Filesystems are made out of blocks of at most MAXBSIZE bytes per block. MAXBSIZE may be made larger without effecting any existing filesystems as long as it does not exceed MAXPHYS, and may be made smaller at the risk of not being able to use filesystems which require a block size exceeding MAXBSIZE. I haven't done any historical research but I think that history behind MAXBSIZE could be something like this. There was only one filesystem and it was UFS. People liked to use statically allocated/sized arrays for various stuff, so they came with a limit for a UFS block size. A sufficiently high and reasonable value was chosen for it. As time passed MAXBSIZE proliferated beyond UFS through VFS and other infrastructure code, partly because for correct reasons, partly because of lazy programming, partly because it just worked. Then, new filesystems had to obey this limit too. MAXBSIZE proliferated even further. And I'd argued that it became a more fundamental constant than what it is documented to be. Nowadays several questions could be asked about MAXBSIZE. - Will we have to consider increasing MAXBSIZE? Provided ever increasing media sizes, typical filesystem sizes, typical file sizes (all that multimedia) and even media sector sizes. - Do we need a universal limit on block size for all filesystems? E.g. ZFS already has maximum block size greater than MAXBSIZE, but it lives (has to live?) in a somewhat parallel world to other filesystems. - What are appropriate and inappropriate uses for MAXBSIZE given the questions above? In other words, what would immediately break were we to simplemindedly bump MAXBSIZE value. I have no answers but have some observations. I strongly believe that all uses of MAXBSIZE in sys/dev/ are inappropriate. For me it's inconceivable that a hardware driver would need to know maximum size of a filesystem block. There are 39 occurrences of MAXBSIZE in sys/dev/. Perhaps DFLTPHYS (currently has the same 64K value) was supposed to be used there? Or even MAXPHYS? Probably each driver needs to be evaluated individually. Curiously enough there are only 14 occurrences of DFLTPHYS in sys/dev/. Feedback welcome. Thanks! -- Andriy Gapon