CEPH filesystem development
 help / color / mirror / Atom feed
From: Willem Jan Withagen <wjw@digiware.nl>
To: "Xinze Chi (信泽)" <xmdxcxz@gmail.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: FreeBSD is receiving traps on os/FileJournal.cc:1036
Date: Wed, 16 Dec 2015 14:45:21 +0100	[thread overview]
Message-ID: <56716AF1.5030800@digiware.nl> (raw)
In-Reply-To: <CANE=7sUnSBUsNGFFURw+hOafAyop=nnUvXG3RYq211zbW5G3SA@mail.gmail.com>

On 16-12-2015 13:51, Xinze Chi (信泽) wrote:
> Would you mind create an issue in http://tracker.ceph.com/ and tell me
> how to reproduce the bug?

You are aware that that requires running FreeBSD?

I will enter a ticket into the tracker.

--WjW


> Thanks.
>
> 2015-12-16 18:26 GMT+08:00 Willem Jan Withagen <wjw@digiware.nl>:
>> On 16-12-2015 10:40, Xinze Chi (信泽) wrote:
>>>
>>> Because we use the new strategy for filejournal in master branch. the
>>> write entry submit to writeq is aligned already.
>>> So if assert at this line, this strategy should have bug.
>>>
>>> I do not know why you have some heads #include, Maybe you modify the
>>> logic in filejournal?
>>
>>
>> No, the adds I've done are to work around the fact that the linux_version
>> stuff
>> is not really going to work for FreeBSD. Not the test, nor the resulting
>> code.
>>
>> So the header part of the file  now looks like:
>> #include "common/blkdev.h"
>> #if defined(__linux__)
>> #include "common/linux_version.h"
>> #endif
>>
>> #if defined(__FreeBSD__)
>> #include "common/freebsd_version.h"
>> #define O_DSYNC O_SYNC
>> #endif
>>
>> The remainder of the diffs are about locking when using aio, which i do not
>> ATM.
>>
>> So never say never with software, but I think I've left the logic as it
>> is/was.
>>
>> --WjW
>>
>>
>>>
>>> 2015-12-16 17:20 GMT+08:00 Willem Jan Withagen <wjw@digiware.nl>:
>>>>
>>>> On 16-12-2015 02:57, Xinze Chi (信泽) wrote:
>>>>>
>>>>> You mean your ceph assert(0 == "bl should be align"), right?
>>>>>
>>>>> But in master branch, the 1036 line is not assert(0 == "bl should be
>>>>> align").
>>>>
>>>>
>>>> Yes you are correct. I think I have some heade #includes why this moves
>>>> down in my file.
>>>>
>>>> None the less I still get trapped on that specific assert.
>>>>
>>>> Next question is of course why this code is what it is. Since once the
>>>> assert triggers, the remainder does not get executed.
>>>> Unless compiled with NDEBUG, then only the warning gets printed.
>>>> But the other asserts never get triggered.
>>>>
>>>> So back to my original question, Why have this very stringent test and
>>>> than in test/buffer.cc forgo the fact that this could/should be aligned.
>>>>
>>>> --WjW
>>>>
>>>>
>>>>> 2015-12-16 7:56 GMT+08:00 Willem Jan Withagen <wjw@digiware.nl>:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm receiving traps when running the tests going with 'gmake check'
>>>>>> and on one of the tests it traps on:
>>>>>>
>>>>>> os/FileJournal.cc:1036
>>>>>> void FileJournal::align_bl(off64_t pos, bufferlist& bl)
>>>>>> {
>>>>>>     // make sure list segments are page aligned
>>>>>>     if (directio && (!bl.is_aligned(block_size) ||
>>>>>>                      !bl.is_n_align_sized(CEPH_MINIMUM_BLOCK_SIZE))) {
>>>>>>       assert(0 == "bl should be align");
>>>>>>       if ((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0 ||
>>>>>>           (pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) != 0)
>>>>>>         dout(0) << "rebuild_page_aligned failed, " << bl << dendl;
>>>>>>       assert((bl.length() & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
>>>>>>       assert((pos & (CEPH_MINIMUM_BLOCK_SIZE - 1)) == 0);
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> And then I get confused with the following commit in other tests:
>>>>>> commit 8ed724222651812c2ee8cc3804dc1f54c973897d
>>>>>> Author: Kefu Chai <kchai@redhat.com>
>>>>>> Date:   Fri Sep 4 01:23:31 2015 +0800
>>>>>>
>>>>>>       test/bufferlist: do not expect !is_page_aligned() after unaligned
>>>>>> rebuild
>>>>>>
>>>>>>       if the size of a bufferlist is page aligned we allocate page
>>>>>> aligned
>>>>>>       memory chunk for it when rebuild() is called. otherwise we just
>>>>>> call
>>>>>>       the plain new() to allocate new memory chunk for holding the
>>>>>> continuous
>>>>>>       buffer. but we should not expect that `new` allocator always
>>>>>> returns
>>>>>>       unaligned memory chunks. instead, it *could* return page aligned
>>>>>>       memory chunk as long as the allocator feels appropriate. so, the
>>>>>>       `EXPECT_FALSE(bl.is_page_aligned())` after the `rebuild()` call is
>>>>>>       removed.
>>>>>>
>>>>>>       Signed-off-by: Kefu Chai <kchai@redhat.com>
>>>>>>
>>>>>> Could these 2 be related, and do I have an alignment problem when
>>>>>> allocating buffers and bufferlists....
>>>>>>
>>>>>> Note that I also have not solved the illegal writes to _len in
>>>>>> bufferlists when running unittest_erasure_code_shec_arguments.
>>>>>>
>>>>>> So any suggestions as to where to look at for this, are welcome.
>>>>>>
>>>>>> --WjW
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
--
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

  reply	other threads:[~2015-12-16 13:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-15 23:56 FreeBSD is receiving traps on os/FileJournal.cc:1036 Willem Jan Withagen
2015-12-16  1:57 ` Xinze Chi (信泽)
2015-12-16  9:20   ` Willem Jan Withagen
2015-12-16  9:40     ` Xinze Chi (信泽)
2015-12-16 10:26       ` Willem Jan Withagen
2015-12-16 12:51         ` Xinze Chi (信泽)
2015-12-16 13:45           ` Willem Jan Withagen [this message]
2015-12-16 20:07           ` Willem Jan Withagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56716AF1.5030800@digiware.nl \
    --to=wjw@digiware.nl \
    --cc=ceph-devel@vger.kernel.org \
    --cc=xmdxcxz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox