Would you mind create an issue in http://tracker.ceph.com/ and tell me how to reproduce the bug? Thanks. 2015-12-16 18:26 GMT+08:00 Willem Jan Withagen <wjw@xxxxxxxxxxx>: > 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@xxxxxxxxxxx>: >>> >>> 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@xxxxxxxxxxx>: >>>>> >>>>> 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@xxxxxxxxxx> >>>>> 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@xxxxxxxxxx> >>>>> >>>>> 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@xxxxxxxxxxxxxxx >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>>> >>>> >>>> >>> >> >> >> > -- Regards, Xinze Chi -- 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
