From patchwork Sun Aug 14 17:24:58 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Somnath Roy X-Patchwork-Id: 9279515 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1837760839 for ; Sun, 14 Aug 2016 17:25:08 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EFAC6289B9 for ; Sun, 14 Aug 2016 17:25:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DE77628A33; Sun, 14 Aug 2016 17:25:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, URI_NOVOWEL autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0D0B7289B9 for ; Sun, 14 Aug 2016 17:25:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752833AbcHNRZE convert rfc822-to-8bit (ORCPT ); Sun, 14 Aug 2016 13:25:04 -0400 Received: from mail-bn3nam01on0057.outbound.protection.outlook.com ([104.47.33.57]:56928 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751987AbcHNRZC (ORCPT ); Sun, 14 Aug 2016 13:25:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandiskcorp.onmicrosoft.com; s=selector1-sandisk-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yO0SahfVdny5cHQQFwI5BQvVlwkFlLoNQXMOkGQwy5k=; b=f3tsNId+qBN3oNK4kKgUy4pHm1V4NC/gBmnS4bTRv7ohRAtXcQmBzuA8TpKx7sbPidgGty6luLxB/NVTSxRqqCax8BilGOwFY/Av3HeCj+s9xuPn/b0Vml2Sqn998icvWcdT2IzdMk7jSEFiVlm2Jpz6W/qvzNshwSJG42v4zvE= Received: from BL2PR02MB2115.namprd02.prod.outlook.com (10.167.97.13) by BL2PR02MB2115.namprd02.prod.outlook.com (10.167.97.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sun, 14 Aug 2016 17:24:58 +0000 Received: from BL2PR02MB2115.namprd02.prod.outlook.com ([10.167.97.13]) by BL2PR02MB2115.namprd02.prod.outlook.com ([10.167.97.13]) with mapi id 15.01.0549.027; Sun, 14 Aug 2016 17:24:58 +0000 From: Somnath Roy To: Sage Weil CC: Mark Nelson , ceph-devel Subject: RE: Bluestore assert Thread-Topic: Bluestore assert Thread-Index: AdHzQ8MNS2EOw+JBS4S8E5qM/8FE6wACX1qAAACSvaAAJWd28AACGPSAAAAqBYAAABHigAALtzGQAAC1KgAAi6yNgA== Date: Sun, 14 Aug 2016 17:24:58 +0000 Message-ID: References: <7dc67e25-4e1c-09a1-8667-ee47572b9290@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Somnath.Roy@sandisk.com; x-originating-ip: [24.5.247.210] x-ms-office365-filtering-correlation-id: 9520f028-0d1c-47fe-5fb3-08d3c467eabe x-microsoft-exchange-diagnostics: 1; BL2PR02MB2115; 20:LdcfcvQ5ZgYH44xacO4tkOBCIV1hXUFY4wh2j3Hvkn5qEvvwA8uC0gdj3U1VbIYjd/S7Z7YvoptRVFQeUHEuRQ2o7GeKiFazO6vDiElM89k5jaeiHIQZbCPgEXTjq8YIb+b0V3zImOJZhfAUdcu7xY4ungiQ7RKaAzdLzDRzSelAcB7fumnxslerApZCy/3E9Lm+kmfI1eUrnjKZAP+Ns2z1f7FCJFImOjzfGOP7m151kUqLmBHfetVs6moqbtU6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR02MB2115; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(9452136761055); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BL2PR02MB2115; BCL:0; PCL:0; RULEID:; SRVR:BL2PR02MB2115; x-forefront-prvs: 00342DD5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(199003)(374574003)(189002)(13464003)(24454002)(189998001)(19580405001)(19580395003)(86362001)(105586002)(15975445007)(8558605004)(4326007)(33656002)(50986999)(76176999)(66066001)(99286002)(54356999)(77096005)(5002640100001)(10400500002)(2900100001)(110136002)(68736007)(221733001)(122556002)(2906002)(2950100001)(551934003)(74316002)(305945005)(8676002)(106356001)(3660700001)(93886004)(11100500001)(3280700002)(81166006)(81156014)(6116002)(102836003)(9686002)(101416001)(76576001)(3846002)(8936002)(7736002)(586003)(7696003)(97736004)(7846002)(92566002)(87936001)(3480700004); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR02MB2115; H:BL2PR02MB2115.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sandisk.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sandisk.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2016 17:24:58.5242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR02MB2115 Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Sage, I did this.. root@emsnode5:~/ceph-master/src# git diff It's not obvious to me how we would get NotFound when doing a Write into the kv store. Thanks! sage > > Thanks & Regards > Somnath > > -----Original Message----- > From: Sage Weil [mailto:sweil@redhat.com] > Sent: Thursday, August 11, 2016 9:36 AM > To: Mark Nelson > Cc: Somnath Roy; ceph-devel > Subject: Re: Bluestore assert > > On Thu, 11 Aug 2016, Mark Nelson wrote: > > Sorry if I missed this during discussion, but why are these being > > called if the file is deleted? > > I'm not sure... rocksdb is the one consuming the interface. Looking through the code, though, this is the only way I can see that we could log an op_file_update *after* an op_file_remove. > > sage > > > > > Mark > > > > On 08/11/2016 11:29 AM, Sage Weil wrote: > > > On Thu, 11 Aug 2016, Somnath Roy wrote: > > > > Sage, > > > > Please find the full log for the BlueFS replay bug in the > > > > following location. > > > > > > > > https://github.com/somnathr/ceph/blob/master/ceph-osd.1.log.zip > > > > > > > > For the db transaction one , I have added code to dump the > > > > rocksdb error code before the assert as you suggested and waiting to reproduce. > > > > > > I'm pretty sure this is the root cause: > > > > > > https://github.com/ceph/ceph/pull/10686 > > > > > > sage > > > -- > > > To unsubscribe from this list: send the line "unsubscribe > > > ceph-devel" in the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > > PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). > > --- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/src/kv/RocksDBStore.cc b/src/kv/RocksDBStore.cc index 638d231..bcf0935 100644 --- a/src/kv/RocksDBStore.cc +++ b/src/kv/RocksDBStore.cc @@ -370,6 +370,10 @@ int RocksDBStore::submit_transaction(KeyValueDB::Transaction t) utime_t lat = ceph_clock_now(g_ceph_context) - start; logger->inc(l_rocksdb_txns); logger->tinc(l_rocksdb_submit_latency, lat); + if (!s.ok()) { + derr << __func__ << " error: " << s.ToString() + << "code = " << s.code() << dendl; + } return s.ok() ? 0 : -1; } @@ -385,6 +389,11 @@ int RocksDBStore::submit_transaction_sync(KeyValueDB::Transaction t) utime_t lat = ceph_clock_now(g_ceph_context) - start; logger->inc(l_rocksdb_txns_sync); logger->tinc(l_rocksdb_submit_sync_latency, lat); + if (!s.ok()) { + derr << __func__ << " error: " << s.ToString() + << "code = " << s.code() << dendl; + } + return s.ok() ? 0 : -1; } int RocksDBStore::get_info_log_level(string info_log_level) @@ -442,7 +451,8 @@ void RocksDBStore::RocksDBTransactionImpl::rmkey(const string &prefix, void RocksDBStore::RocksDBTransactionImpl::rm_single_key(const string &prefix, const string &k) { - bat->SingleDelete(combine_strings(prefix, k)); + //bat->SingleDelete(combine_strings(prefix, k)); + bat->Delete(combine_strings(prefix, k)); } But, the db crash is still happening with the following log message. rocksdb: submit_transaction_sync error: NotFound: code = 1 It seems it is not related to rm_single_key as I am hitting this from https://github.com/ceph/ceph/blob/master/src/os/bluestore/BlueStore.cc#L5108 as well where rm_single_key is not called. May be I should dump the transaction and see what's in there ? I am hitting the BlueFS replay bug I mentioned earlier and applied your patch (https://github.com/ceph/ceph/pull/10686) but not helping. Is it because I needed to run with this patch from the beginning and not just during replay ? Thanks & Regards Somnath -----Original Message----- From: Sage Weil [mailto:sweil@redhat.com] Sent: Thursday, August 11, 2016 3:32 PM To: Somnath Roy Cc: Mark Nelson; ceph-devel Subject: RE: Bluestore assert On Thu, 11 Aug 2016, Somnath Roy wrote: > Sage, > Regarding the db assert , I hit that again on multiple OSDs while I was populating 40TB rbd images (~35TB written before crash). > I did the following changes in the code.. > > @@ -370,7 +370,7 @@ int RocksDBStore::submit_transaction(KeyValueDB::Transaction t) > utime_t lat = ceph_clock_now(g_ceph_context) - start; > logger->inc(l_rocksdb_txns); > logger->tinc(l_rocksdb_submit_latency, lat); > - return s.ok() ? 0 : -1; > + return s.ok() ? 0 : -s.code(); > } > > int RocksDBStore::submit_transaction_sync(KeyValueDB::Transaction t) > @@ -385,7 +385,7 @@ int RocksDBStore::submit_transaction_sync(KeyValueDB::Transaction t) > utime_t lat = ceph_clock_now(g_ceph_context) - start; > logger->inc(l_rocksdb_txns_sync); > logger->tinc(l_rocksdb_submit_sync_latency, lat); > - return s.ok() ? 0 : -1; > + return s.ok() ? 0 : -s.code(); > } > int RocksDBStore::get_info_log_level(string info_log_level) { diff > --git a/src/os/bluestore/BlueStore.cc b/src/os/bluestore/BlueStore.cc > index fe7f743..3f4ecd5 100644 > --- a/src/os/bluestore/BlueStore.cc > +++ b/src/os/bluestore/BlueStore.cc > @@ -4989,6 +4989,9 @@ void BlueStore::_kv_sync_thread() > ++it) { > _txc_finalize_kv((*it), (*it)->t); > int r = db->submit_transaction((*it)->t); > + if (r < 0 ) { > + dout(0) << "submit_transaction returned = " << r << dendl; > + } > assert(r == 0); > } > } > @@ -5026,6 +5029,10 @@ void BlueStore::_kv_sync_thread() > t->rm_single_key(PREFIX_WAL, key); > } > int r = db->submit_transaction_sync(t); > + if (r < 0 ) { > + dout(0) << "submit_transaction_sync returned = " << r << dendl; > + } > + > assert(r == 0); > > > This is printing -1 in the log before asset. So, the corresponding code from the rocksdb side is "kNotFound". > It is not related to space as I hit this same issue irrespective of db partition size is 100G or 300G. > It seems some kind of corruption within Bluestore ? > Let me now the next step. Can you add this too? diff --git a/src/kv/RocksDBStore.cc b/src/kv/RocksDBStore.cc index 638d231..b5467f7 100644 --- a/src/kv/RocksDBStore.cc +++ b/src/kv/RocksDBStore.cc @@ -370,6 +370,9 @@ int RocksDBStore::submit_transaction(KeyValueDB::Transaction t) utime_t lat = ceph_clock_now(g_ceph_context) - start; logger->inc(l_rocksdb_txns); logger->tinc(l_rocksdb_submit_latency, lat); + if (!s.ok()) { + derr << __func__ << " error: " << s.ToString() << dendl; } return s.ok() ? 0 : -1; }