From owner-freebsd-geom@FreeBSD.ORG Sun Dec 28 23:44:04 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A7F2EC5; Sun, 28 Dec 2014 23:44:04 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0069.outbound.protection.outlook.com [207.46.100.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 968F31D6A; Sun, 28 Dec 2014 23:44:02 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0942.namprd08.prod.outlook.com (25.160.131.25) with Microsoft SMTP Server (TLS) id 15.1.49.12; Sun, 28 Dec 2014 20:09:54 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.01.0049.002; Sun, 28 Dec 2014 20:09:54 +0000 From: "Pokala, Ravi" To: Poul-Henning Kamp , Adrian Chadd Subject: Re: Converting LBAs to byte offsets through the GEOM stack Thread-Topic: Converting LBAs to byte offsets through the GEOM stack Thread-Index: AQHQGxf+kE6X/QdjbU+vuIDpLz2I5ZyWJp0A//9/yoCAAlgOAIAAYqmAgACXpICAAAbDgIAMGi+A Date: Sun, 28 Dec 2014 20:09:54 +0000 Message-ID: References: <20141219015210.GY25139@funkthat.com> <13564.1419110461@critter.freebsd.dk> In-Reply-To: <13564.1419110461@critter.freebsd.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [98.198.65.138] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0942; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0942; x-forefront-prvs: 0439571D1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(164054003)(86362001)(36756003)(101416001)(50986999)(97736003)(99396003)(77156002)(83506001)(62966003)(120916001)(93886004)(2656002)(122556002)(4396001)(54356999)(21056001)(76176999)(92566001)(40100003)(46102003)(2900100001)(105586002)(2950100001)(106356001)(106116001)(68736005)(66066001)(102836002)(31966008)(99286002)(64706001)(20776003)(87936001)(107046002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0942; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2014 20:09:54.6630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB0942 Cc: John-Mark Gurney , "freebsd-geom@freebsd.org" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2014 23:44:04 -0000 Hi Poul-Henning, >If this were important, the geom(8) tool could probably do it, based on >the exported XML state of the geom-mesh and support modules mirroring >actual logic for all relevant geoms, that way it would at least live in >userland. I did some digging in our source tree, and it turns out that someone implemented something like that (userland tool, using geom_gettree() to get the mesh, forward- and reverse-map for various GEOMs) for some of the GEOMs we use. Unfortunately, some of the important classes were left out, and it requires changes for each additional class we want to support. And, as several people have mentioned, it only works for classes which perform fixed mappings rather than dynamic mappings. The good news is, I'm only interested in static mappings, so I should be able to come up with something to fulfill my needs. With those caveats (code required for each additional class, only works for static mappings), would this be something others are interested in having? Thanks, Ravi