From owner-freebsd-geom@FreeBSD.ORG Thu Apr 22 21:59:31 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 673FD1065672 for ; Thu, 22 Apr 2010 21:59:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AD78F8FC13 for ; Thu, 22 Apr 2010 21:59:30 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA16055 for ; Fri, 23 Apr 2010 00:59:29 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O54Qi-0008bd-Sp for freebsd-geom@FreeBSD.org; Fri, 23 Apr 2010 00:59:28 +0300 Message-ID: <4BD0C6C0.30008@icyb.net.ua> Date: Fri, 23 Apr 2010 00:59:28 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: d_maxsize .. si_iosize_max 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: Thu, 22 Apr 2010 21:59:31 -0000 I see that many disk drivers are careful to set an optimal value for d_maxsize. On the other hand, si_iosize_max is hardcoded to MAXPHYS in geom_dev.c, which leads to suboptimal I/O for devices with actual maximum I/O size less than MAXPHYS. And right now d_maxsize seems to be used only for dumperinfo.maxiosize, which is a waste. So, perhaps, d_maxsize should be passed up through GEOM layer as a provider property, e.g. pp->maxiosize. So that si_iosize_max could be set correctly. Or, more importantly, so that final consumers (e.g. filesystems) could now correct optimal I/O size. Perhaps, this should even be split into max_read_size and max_write_size for geoms like gmirror where reads can be done in parallel. -- Andriy Gapon