From owner-freebsd-arch@FreeBSD.ORG Tue Jul 7 16:36:42 2009 Return-Path: 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 AD25C106564A; Tue, 7 Jul 2009 16:36:42 +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 5DA418FC0A; Tue, 7 Jul 2009 16:36:42 +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 n67Gagkp087661; Tue, 7 Jul 2009 09:36:42 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n67GagxN087660; Tue, 7 Jul 2009 09:36:42 -0700 (PDT) Date: Tue, 7 Jul 2009 09:36:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200907071636.n67GagxN087660@apollo.backplane.com> To: Alexander Motin References: <1246746182.00135530.1246735202@10.7.7.3> <1246792983.00135712.1246781401@10.7.7.3> <1246796580.00135722.1246783203@10.7.7.3> <1246814582.00135806.1246803602@10.7.7.3> <1246818181.00135809.1246804804@10.7.7.3> <1246825383.00135846.1246812602@10.7.7.3> <1246825385.00135854.1246814404@10.7.7.3> <1246830930.00135868.1246819202@10.7.7.3> <1246830933.00135875.1246820402@10.7.7.3> <1246908182.00136258.1246896003@10.7.7.3> <1246911786.00136277.1246900203@10.7.7.3> <1246915383.00136290.1246904409@10.7.7.3> <4A534D05.1040709@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 16:36:43 -0000 :You are mixing completely different things. I was never talking about :file system block size. I am not trying to argue that 16/32K file system :block size may be quite effective in most of cases. I was speaking about :maximum _disk_transaction_ size. It is not the same. : :When file system needs small amount of data, or there is just small :file, there is definitely no need to read/write more then one small FS :block. But instead, when file system prognoses effective large :read-ahead or it have a lot of write-back data, there is no reason to :not transfer more contiguous blocks with one big disk transaction. :Splitting it will just increase command overhead at all layers and make :possible drive to be interrupted between that operations to do some very :long seek. :-- :Alexander Motin That isn't correct. Locality of reference for adjacent data is very important even if the filesystem only needs a small amount of data. A good example of this would be accessing the inode area in a UFS cylinder. Issuing only a single filesystem block read in the inode area is a huge lose verses issueing a cluster read of 64K (4-8 filesystem blocks), particularly if the inode is being accessed as part of a 'find' or 'ls -lR'. I have not argued that the maximum device block size is important, I've simply argued that it is convenient. What is important, and I stressed this in my argument several times, is the total number of bytes the cluster_read() code reads when the filesystem requests a particular filesystem block. -Matt Matthew Dillon