From owner-freebsd-fs@FreeBSD.ORG Thu Dec 20 23:36:51 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E390116A421; Thu, 20 Dec 2007 23:36:51 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id A14E313C448; Thu, 20 Dec 2007 23:36:51 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se (c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.130]) by smtp.infidyne.com (Postfix) with ESMTP id 4C1B57785C; Fri, 21 Dec 2007 00:36:50 +0100 (CET) From: Peter Schuller To: ticso@cicely.de Date: Fri, 21 Dec 2007 00:36:40 +0100 User-Agent: KMail/1.9.7 References: <200712202140.08367.peter.schuller@infidyne.com> <20071220221735.GB67140@cicely12.cicely.de> In-Reply-To: <20071220221735.GB67140@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2867901.o7Q3KWBikV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712210036.49040.peter.schuller@infidyne.com> Cc: freebsd-fs@freebsd.org, Ivan Voras Subject: Re: readv: parallel or sequential? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2007 23:36:52 -0000 --nextPart2867901.o7Q3KWBikV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > In case the application uses serialized access there is not much to do > beside preread or caching writes to make use of multiple spindles. Agreed. > But an application has to be carefull, because parallel access within > a single file almost always mean that access is not linear anymore, so > many opther performance tunings won't work as good as they could, so > this could easily outweight the performance gain from multiple access. =46or seek bound applications you don't really care anyway. If you have a=20 mixture of stream bound and seak bound I/O going on you will run into vario= us=20 issues which are difficult to avoid without very careful application-specif= ic=20 tuning I think. But for the simple case of doing concurrent seek-bound I/O = I=20 would expect it to be handled gracefully by the OS. And I do mean to the same file, rather than file descriptor (in response to= =20 the other post on descriptors). > Nonlinear access from within an application has to be for another reason > and not as a performance tuning. Why? Again, PostgreSQL, other databases, or any file access pattern which i= s=20 seek bound stands to gain more or less linearly from concurrent I/O being=20 propagated to constituent devices in a non-serialized fashion. This is a=20 pretty basic assumption in my book when designing an application. Whenever= =20 something is seek bound, assuming I have concurrency in my app, I look at t= he=20 number of constituent devices on the device and the type of RAID or similar= =20 being used (including stripe sizes in relation to the size of my I/O=20 requests, etc). I fully expect to be able to scale linearly with the number of underlying=20 devices, assuming raid0/raid10 or something equivalent, and assuming I have= a=20 concurrency that is sufficiently high to keep all drives busy. (There are valid exceptions of course, such as raidz/raidz2. But that's bey= ond=20 the scope of this discussion.) =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart2867901.o7Q3KWBikV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHavyQDNor2+l1i30RAn9BAJ4ookJhNAFYuq2ft6B+Gb2TcU4wKgCeI6mI /9J8DnwEekbyfZcTLUEO/+Y= =P/2n -----END PGP SIGNATURE----- --nextPart2867901.o7Q3KWBikV--