From owner-freebsd-arch@FreeBSD.ORG Tue Aug 18 10:54:16 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 0206D106568F for ; Tue, 18 Aug 2009 10:54:16 +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 4C0208FC3D for ; Tue, 18 Aug 2009 10:54:14 +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 NAA22324 for ; Tue, 18 Aug 2009 13:43:58 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A8A85ED.4090404@freebsd.org> Date: Tue, 18 Aug 2009 13:43:57 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: freebsd-arch@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: on architecture of dumping 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, 18 Aug 2009 10:54:16 -0000 I think that the following is quite obvious, but it needs to be said anyway. I think that we should switch from current approach of hierarchically configuring dumper to having a hierarchy of dumpers. Right now only disks provide dumping routines and the layers above disks can only set offset and size of dump area. This results in the following limitations: 1. dump can be made only to contiguous area of a disk 2. dump can be made only to a single disk Having a hierarchy of dumpers is a need that arises from having a GEOM hierarchy. I think that each compliant GEOM provider could expose a dump method for writing out a blob of data to certain offset within the provider. Such a dump routine would dispatch data to dump methods of underlying provider(s) according to provider's logic. Disk providers would have almost the same dump routines as they do now (they are actually in disk drivers). This would allow, for example, mirrored dumping to gmirror devices. And this would pave a way for porting dumping to a zvol from OpenSolaris. Please comment. Thank you. -- Andriy Gapon