https://tracker.ceph.com/
https://tracker.ceph.com/favicon.ico
2019-09-12T16:49:52Z
Ceph
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=145984
2019-09-12T16:49:52Z
Xiaoxi Chen
xiaoxchen@ebay.com
<ul></ul><p>The issue affect all releases including master</p>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=146116
2019-09-13T19:06:40Z
Patrick Donnelly
pdonnell@redhat.com
<ul><li><strong>Subject</strong> changed from <i>FAILED assert(cap == in->auth_cap)</i> to <i>client: FAILED assert(cap == in->auth_cap)</i></li><li><strong>Target version</strong> set to <i>v15.0.0</i></li><li><strong>Start date</strong> deleted (<del><i>09/12/2019</i></del>)</li><li><strong>Source</strong> set to <i>Community (dev)</i></li><li><strong>Component(FS)</strong> <i>Client</i> added</li><li><strong>Component(FS)</strong> deleted (<del><i>ceph-fuse</i></del>)</li></ul>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=146224
2019-09-16T13:51:32Z
Zheng Yan
ukernel@gmail.com
<ul><li><strong>Assignee</strong> set to <i>Zheng Yan</i></li></ul>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=146255
2019-09-16T20:09:16Z
Patrick Donnelly
pdonnell@redhat.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Fix Under Review</i></li><li><strong>Assignee</strong> changed from <i>Zheng Yan</i> to <i>Xiaoxi Chen</i></li><li><strong>Pull request ID</strong> set to <i>30402</i></li><li><strong>Labels (FS)</strong> <i>offline</i> added</li></ul>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=146269
2019-09-17T03:46:59Z
Zheng Yan
ukernel@gmail.com
<ul></ul><p>I'd like to know why the cap import message's seq is 1, mseq is 0. please use gdb to print cap import message's peer information. (f 8, p m->peer)</p>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=146390
2019-09-18T03:17:40Z
Xiaoxi Chen
xiaoxchen@ebay.com
<ul></ul><p>(gdb) p m->peer<br />$1 = {cap_id = {v = 2782052343}, seq = {v = 4}, mseq = {v = 0}, mds = {v = 1}, flags = 2 '\002'}</p>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=147847
2019-10-07T18:50:23Z
Xiaoxi Chen
xiaoxchen@ebay.com
<ul></ul><p>@Zheng,</p>
<p>any update or anything we can help?</p>
<p>seems like we can change from<br /><pre>
if (ceph_seq_cmp(seq, cap.seq) <= 0) {
</pre><br />to <br /><pre>
if (ceph_seq_cmp(seq, cap.seq) < 0) {
</pre><br />as ceph_seq_cmp(seq, cap.seq) ==0 indicating exactly the import_cap message.</p>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=148256
2019-10-10T06:57:36Z
Xiaoxi Chen
xiaoxchen@ebay.com
<ul></ul><p>One more victim on 13.2.5<br /><pre>
-4> 2019-09-28 09:01:50.156 7fe6799e3700 1 -- 10.206.140.28:0/1309002991 <== mds.0 10.218.2.224:6800/2026541741 2 ==== client_caps(import ino 0x1000598f6bb 1913515435 seq 1 caps=pAsLsXsFs dirty=- wanted=- follows 0 mseq 1 size 0/0 ts 1/18446744073709551615 mtime 2019-06-05 17:21:06.348736 xattrs(v=1 l=4)) v11 ==== 321+4+0 (3926379498 0 0) 0x564a110b9680 con 0x564a111d7e00
-3> 2019-09-28 09:01:50.156 7fe6799e3700 5 client.197381312 handle_cap_import ino 0x1000598f6bb mseq 1 IMPORT from mds.0
-2> 2019-09-28 09:01:50.156 7fe67c9e9700 5 -- 10.206.140.28:0/1309002991 >> 10.156.69.192:6789/0 conn(0x564a11373000 :-1 s=STATE_OPEN_MESSAGE_READ_FOOTER_AND_DISPATCH pgs=16068008 cs=1 l=1). rx mon.3 seq 143 0x564a113da500 osd_map(4050054..4050054 src has 4050054..4072219) v3
-1> 2019-09-28 09:01:50.156 7fe67c9e9700 5 -- 10.206.140.28:0/1309002991 >> 10.156.69.192:6789/0 conn(0x564a11373000 :-1 s=STATE_OPEN_MESSAGE_READ_FOOTER_AND_DISPATCH pgs=16068008 cs=1 l=1). rx mon.3 seq 144 0x564a115a5b80 osd_map(4050055..4050059 src has 4050054..4072219) v3
0> 2019-09-28 09:01:50.156 7fe6799e3700 -1 /home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/huge/release/13.2.5/rpm/el7/BUILD/ceph-13.2.5/src/client/Client.cc: In function 'void Client::add_update_cap(Inode*, MetaSession*, uint64_t, unsigned int, unsigned int, unsigned int, inodeno_t, int, const UserPerm&)' thread 7fe6799e3700 time 2019-09-28 09:01:50.158860
/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/huge/release/13.2.5/rpm/el7/BUILD/ceph-13.2.5/src/client/Client.cc: 3936: FAILED assert(&cap == in->auth_cap)
ceph version 13.2.5 (cbff874f9007f1869bfd3821b7e33b2a6ffd4988) mimic (stable)
1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0xff) [0x7fe685611fbf]
2: (()+0x26d187) [0x7fe685612187]
3: (Client::add_update_cap(Inode*, MetaSession*, unsigned long, unsigned int, unsigned int, unsigned int, inodeno_t, int, UserPerm const&)+0x945) [0x564a101ccfd5]
4: (Client::handle_cap_import(MetaSession*, Inode*, MClientCaps*)+0x26a) [0x564a101ce89a]
5: (Client::handle_caps(MClientCaps*)+0x5d1) [0x564a102037f1]
6: (Client::ms_dispatch(Message*)+0x41b) [0x564a1020c0cb]
7: (DispatchQueue::entry()+0xb7a) [0x7fe6856ce39a]
8: (DispatchQueue::DispatchThread::entry()+0xd) [0x7fe68576c2cd]
9: (()+0x7dd5) [0x7fe683648dd5]
10: (clone()+0x6d) [0x7fe682521ead]
NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.
</pre></p>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=148533
2019-10-14T09:15:07Z
Zheng Yan
ukernel@gmail.com
<ul></ul><p>Sorry for the delay</p>
<p>I understand what happened. (two mds exported non-auth caps )</p>
<p>PR#30402 is a good workaround.</p>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=150252
2019-11-01T22:55:25Z
Patrick Donnelly
pdonnell@redhat.com
<ul><li><strong>Status</strong> changed from <i>Fix Under Review</i> to <i>Pending Backport</i></li><li><strong>Backport</strong> set to <i>nautilus,mimic</i></li></ul>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=150436
2019-11-04T21:47:13Z
Nathan Cutler
ncutler@suse.cz
<ul><li><strong>Copied to</strong> <i><a class="issue tracker-9 status-3 priority-4 priority-default closed" href="/issues/42631">Backport #42631</a>: nautilus: client: FAILED assert(cap == in->auth_cap)</i> added</li></ul>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=150438
2019-11-04T21:47:20Z
Nathan Cutler
ncutler@suse.cz
<ul><li><strong>Copied to</strong> <i><a class="issue tracker-9 status-6 priority-4 priority-default closed" href="/issues/42632">Backport #42632</a>: mimic: client: FAILED assert(cap == in->auth_cap)</i> added</li></ul>
CephFS - Bug #41799: client: FAILED assert(cap == in->auth_cap)
https://tracker.ceph.com/issues/41799?journal_id=165532
2020-05-11T14:31:10Z
Nathan Cutler
ncutler@suse.cz
<ul><li><strong>Status</strong> changed from <i>Pending Backport</i> to <i>Resolved</i></li></ul><p>While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".</p>