From owner-svn-src-all@FreeBSD.ORG Wed Jan 6 20:01:31 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5C5C106566C; Wed, 6 Jan 2010 20:01:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 37C3E8FC16; Wed, 6 Jan 2010 20:01:30 +0000 (UTC) Received: from c122-106-170-81.carlnfd1.nsw.optusnet.com.au (c122-106-170-81.carlnfd1.nsw.optusnet.com.au [122.106.170.81]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o06K1SwI017802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 07:01:29 +1100 Date: Thu, 7 Jan 2010 07:01:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Ivan Voras In-Reply-To: <9bbcef731001061103u33fd289q727179454b21ce18@mail.gmail.com> Message-ID: <20100107065127.U55530@delplex.bde.org> References: <201001061712.o06HCICF087127@svn.freebsd.org> <9bbcef731001060938k2b0014a2m15eef911b9922b2c@mail.gmail.com> <4B44D8FA.2000608@FreeBSD.org> <9bbcef731001061103u33fd289q727179454b21ce18@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, Alexander Motin , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r201658 - head/sbin/geom/class/stripe X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 20:01:31 -0000 On Wed, 6 Jan 2010, Ivan Voras wrote: > 2010/1/6 Alexander Motin : >> Ivan Voras wrote: > >>> I think there was one more reason - though I'm not sure if it is still >>> valid because of your current and future work - the MAXPHYS >>> limitation. If MAXPHYS is 128k, with 64k stripes data was only to be >>> read from maximum of 2 drives. With 4k stripes it would have been read >>> from 128/4=32 drives, though I agree 4k is too low in any case >>> nowadays. I usually choose 16k or 32k for my setups. >> >> While you are right about MAXPHYS influence, and I hope we can rise it >> not so far, IMHO it is file system business to manage deep enough >> read-ahead/write-back to make all drives busy, independently from >> MAXPHYS value. With small MAXPHYS value FS should just generate more >> requests in advance. Except some RAID3/5/6 cases, where short writes >> ineffective, MAXPHYS value should only affect processing overhead. > > Yes, my experience which lead to the post was mostly on UFS which, > while AFAIK it does read-ahead, it still does it serially (I think > this is implied by your experiments with NCQ and ZFS vs UFS) - so in > any case only 2 drives are hit with 64k stripe size at any moment in > time. fsck has no signifcant knowledge of read-ahead. Normally it uses vfs read clustering, which under the most favourable circumstances reduces to read-ahead of a maxiumum of MAXPHYS (less the initial size). If read clustering is disabled, then ffs does old-style read-ahead of a whole block (16K). Most file systems in FreeBSD are similar or worse (some support a block size of 512 and reading ahead by that amount gives interestingly slow behaviour). Bruce