From owner-freebsd-arch@FreeBSD.ORG  Tue Jul  7 17:10:29 2009
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 41874106566C
	for <freebsd-arch@FreeBSD.org>; Tue,  7 Jul 2009 17:10:29 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.freebsd.org (Postfix) with ESMTP id 1A6FE8FC22
	for <freebsd-arch@FreeBSD.org>; Tue,  7 Jul 2009 17:10:28 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n67HASDN088249
	for <freebsd-arch@FreeBSD.org>; Tue, 7 Jul 2009 10:10:28 -0700 (PDT)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.14.2/8.13.4/Submit) id n67HASb7088248;
	Tue, 7 Jul 2009 10:10:28 -0700 (PDT)
Date: Tue, 7 Jul 2009 10:10:28 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200907071710.n67HASb7088248@apollo.backplane.com>
To: freebsd-arch@FreeBSD.org
References: <20090707151901.GA63927@les.ath.cx>
	<200907071639.n67GdBD2087690@apollo.backplane.com>
Cc: 
Subject: Re: DFLTPHYS vs MAXPHYS
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2009 17:10:29 -0000

    A more insideous problem here that I think is being missed is
    the fact that newer filesystems are starting to use larger filesystem
    block sizes.  I myself hit serious issues when I tried to create a
    UFS filesystem with a 64K basic filesystem block size a few years ago,
    and I hit similar issues with HAMMER which uses 64K buffers for bulk
    data which I had to fix by reincorporating code into ATA that had existed
    originally to break-up large single-transfer requests that exceeded the
    chipset's DMA capability.  In the case of ATA, numerous older chips
    can't even do 64K due to bugs in the DMA hardware.  Their maximum is
    actually 65024 bytes.

    Traditionally the cluster code enforced such limits but assumed that
    the basic filesystem block size would be small enough not to hit the
    limits.  It becomes a real problem when the filesystem itself wants to
    use a large basic block size. 

    In that respect hardware which is limited to 64K has serious consequences
    which cascade through to the VFS layers.

						-Matt