Stupid allocator assert during replay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sage,
Regarding the replay assert I posted yesterday , it seems it is happening only with Stupid and *not* with bitmap allocator.


Thread 1 "ceph-osd" received signal SIGABRT, Aborted.
0x00007ffff47fd418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff47fd418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff47ff01a in __GI_abort () at abort.c:89
#2  0x0000555555fa114b in ceph::__ceph_assert_fail (assertion=assertion@entry=0x5555562460ed "rm.empty()",
    file=file@entry=0x555556245fd8 "/root/ceph-master/src/os/bluestore/StupidAllocator.cc", line=line@entry=305,
    func=func@entry=0x5555562462c0 <StupidAllocator::init_rm_free(unsigned long, unsigned long)::__PRETTY_FUNCTION__> "virtual void StupidAllocator::init_rm_free(uint64_t, uint64_t)") at /root/ceph-master/src/common/assert.cc:78
#3  0x0000555555df6d5c in StupidAllocator::init_rm_free (this=0x55555f06f7a0, offset=<optimized out>, length=<optimized out>)
    at /root/ceph-master/src/os/bluestore/StupidAllocator.cc:305
#4  0x0000555555dd33aa in BlueFS::mount (this=0x55555f266580) at /root/ceph-master/src/os/bluestore/BlueFS.cc:366
#5  0x0000555555d017e5 in BlueStore::_open_db (this=this@entry=0x55555f162000, create=create@entry=false) at /root/ceph-master/src/os/bluestore/BlueStore.cc:3008
#6  0x0000555555d1c02d in BlueStore::mount (this=0x55555f162000) at /root/ceph-master/src/os/bluestore/BlueStore.cc:3659
#7  0x0000555555924ef3 in OSD::init (this=0x55555f14a000) at /root/ceph-master/src/osd/OSD.cc:2025
#8  0x00005555558838ff in main (argc=<optimized out>, argv=<optimized out>) at /root/ceph-master/src/ceph_osd.cc:609


Debugging further and printing some extra log , I found this..

    -9> 2016-09-14 14:33:41.581325 7fbfde2608c0 10 stupidalloc init_rm_free 45120225280~2097152
    -8> 2016-09-14 14:33:41.581326 7fbfde2608c0 20 stupidalloc init_rm_free bin 9 rm [45120225280~2097152]
    -7> 2016-09-14 14:33:41.581327 7fbfde2608c0 30 stupidalloc init_rm_free rm = []
    -6> 2016-09-14 14:33:41.581328 7fbfde2608c0 10 stupidalloc init_rm_free 45123371008~2097152
    -5> 2016-09-14 14:33:41.581329 7fbfde2608c0 20 stupidalloc init_rm_free bin 9 rm [45123371008~2097152]
    -4> 2016-09-14 14:33:41.581330 7fbfde2608c0 30 stupidalloc init_rm_free rm = []
    -3> 2016-09-14 14:33:41.581331 7fbfde2608c0 30 bluefs mount noting alloc for file(ino 0 size 0x1000 mtime 2016-09-14 14:16:10.853017 bdev 0 extents [1:0x15500000+100000])
    -2> 2016-09-14 14:33:41.581332 7fbfde2608c0 10 stupidalloc init_rm_free 357564416~1048576
    -1> 2016-09-14 14:33:41.581333 7fbfde2608c0 30 stupidalloc init_rm_free rm = [357564416~1048576]
     0> 2016-09-14 14:33:41.583530 7fbfde2608c0 -1 /root/ceph-master/src/os/bluestore/StupidAllocator.cc: In function 'virtual void StupidAllocator::init_rm_free(uint64_t, uint64_t)' thread 7fbfde2608c0 time 2016-09-14 14:33:41.581339
/root/ceph-master/src/os/bluestore/StupidAllocator.cc: 306: FAILED assert(rm.empty())


So, for inode 0 it is not entering in the following loop from where rm is freed.

  for (unsigned i = 0; i < free.size() && !rm.empty(); ++i) {

So, it seems free.size is 0 at this point , not sure why though ?

I have full verbose log , let me know if you need that.

Thanks & Regards
Somnath
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux