From owner-freebsd-geom@FreeBSD.ORG Fri Dec 19 02:47:17 2014 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E36F712F for ; Fri, 19 Dec 2014 02:47:16 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0099.outbound.protection.outlook.com [157.56.110.99]) (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 8010CC9F for ; Fri, 19 Dec 2014 02:47:15 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0943.namprd08.prod.outlook.com (25.160.131.26) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 19 Dec 2014 02:13:20 +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.0031.000; Fri, 19 Dec 2014 02:13:20 +0000 From: "Pokala, Ravi" To: John-Mark Gurney 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/yoA= Date: Fri, 19 Dec 2014 02:13:19 +0000 Message-ID: References: <20141219015210.GY25139@funkthat.com> In-Reply-To: <20141219015210.GY25139@funkthat.com> 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: [64.80.217.3] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0943; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0801MB0943; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(107046002)(83506001)(50986999)(64706001)(2656002)(4396001)(99396003)(86362001)(110136001)(66066001)(87936001)(106116001)(20776003)(46102003)(99286002)(106356001)(21056001)(120916001)(62966003)(122556002)(97736003)(54356999)(76176999)(105586002)(102836002)(68736005)(101416001)(77156002)(40100003)(36756003)(2900100001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0943; 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 Cc: "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: Fri, 19 Dec 2014 02:47:17 -0000 > I've only done this manually... It isn't too hard, as all the >partitioning schemes are simple offsets, and the stripe should be >regular... The *partitioning schemes*, yes. But once you start building up more layers, it gets complicated. > The issue w/ manually mapping, is that you might loose a race w/ the >mirror when writing out new data... Yeah, I described it the way I did because I'm trying to avoid discussing some proprietary details. :-P It was "close enough" for you to get the idea what I was talking about. > I was thinking it would be good for gmirror to grow a mode that when it >detects a pending sector or offline sector, to figure out via some >mapping, what data needed to be fixed, and attempt to read/write the data >back... What you're talking about would be called "sector resilvering", or perhaps "on-the-fly resilvering" - rebuilding the mirror for just sectors that we know are bad, without having to re-mirror the entire device. Panasas actually implemented that in gmirror on our old 7.2-RELEASE-based system, and we are planning on porting it forward to a 10.1-RELEASE-based (or better still -CURRENT-based) system in the near future; when we do that, we'll submit it. > Even having a simple mode that upon read error, would read from the >other drive and write back would be good... Yes, that's exactly what we (Panasas) implemented. -Ravi