From owner-freebsd-geom@FreeBSD.ORG Fri Dec 10 14:48:27 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AFE31065672; Fri, 10 Dec 2010 14:48:27 +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 728E78FC15; Fri, 10 Dec 2010 14:48:26 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA09006; Fri, 10 Dec 2010 16:48:24 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4D023DB7.9080509@freebsd.org> Date: Fri, 10 Dec 2010 16:48:23 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lev Serebryakov References: <1365605559.20101210162253@serebryakov.spb.ru> In-Reply-To: <1365605559.20101210162253@serebryakov.spb.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Where userland read/write requests, whcih is larger than MAXPHYS, are splitted? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 14:48:27 -0000 on 10/12/2010 15:22 Lev Serebryakov said the following: > Hello, Freebsd-geom. > > I'm digging thought GEOM/IO code and can not find place, where > requests from userland to read more than MAXPHYS bytes, is splitted > into several "struct bio"? Check out g_disk_start(). The split is done based on disk-specific d_maxsize, not hardcoded MAXPHYS, of course. > It seems, that these children request are issued one-by-one, not in > parallel, am I right? Why? It breaks down parallelism, when > underlying GEOM can process several requests simoltaneously? How do you *issue* the child requests in parallel? Of course, they can *run* in parallel if system configuration permits that and request run time is sufficient for an overlap to happen. Besides, there are no geoms under disk geom, it works on peripheral drivers. But maybe I misunderstood your question and you talked about a different I/O layer or different I/O path. -- Andriy Gapon