OK, I've figured this out - There's a signed vs unsigned issue that only comes up with discards and OBD_OBJECT_EOF. Working on a patch.
Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35302
Subject: LU-12462 llite: correct fsync arguments
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 8217176edefb34c6ec5de07f2e778386fff6b6d4
green, jamesanunez :
This failure has only been seen in "full" testing, and I'm not sure how to invoke that for my patch. Can one of you do that?
Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35339
Subject: LU-12462 llite: Remove old fsync versions
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: a030f9c6123d8e3e1d377da32ee05ea3765bf596
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35339/
Subject: LU-12462 llite: Remove old fsync versions
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 4cb6ce1863d0498ece59dabe6d38ef12c0a5fd41
The failure isn't limited by signed vs unsigned issue.
OST extent is created with wrong oe_start in case of existing DoM extent.
os_start is aligned to cl_chunkbits=20, so it is 0 with 262144 index which is real start of OST extent.
crash> osc_extent.oe_start,oe_end ffff90895c8b7d10 oe_start = 0 oe_end = 255
ci_fsync = {
fi_start = 262144,
fi_end = -1,
fi_fid = 0xffff908956911b18,
fi_mode = CL_FSYNC_DISCARD,
fi_nr_written = 0
},
00000080:00200000:0.0:1560698103.488527:0:6682:0:(file.c:357:ll_file_release()) VFS Op:inode=[0x200000403:0x1350:0x0](ffff908956911b90)
00010000:00010000:0.0:1560698103.490992:0:12953:0:(ldlm_lockd.c:1715:ldlm_handle_bl_callback()) ### client blocking AST callback handler ns: lustre-MDT0000-mdc-ffff90897640f000 lock: ffff9089ec0ee000/0xeb72e01621e5d8a8 lrc: 3/0,0 mode: PW/PW res: [0x200000403:0x1350:0x0].0x0 bits 0x40/0x0 rrc: 3 type: IBT flags: 0x400080010000 nid: local remote: 0x76683b3d6040c693 expref: -99 pid: 6682 timeout: 0 lvb_type: 0
00010000:00010000:0.0:1560698103.490997:0:12953:0:(ldlm_request.c:1318:ldlm_cli_cancel_local()) ### client-side cancel ns: lustre-MDT0000-mdc-ffff90897640f000 lock: ffff9089ec0ee000/0xeb72e01621e5d8a8 lrc: 4/0,0 mode: PW/PW res: [0x200000403:0x1350:0x0].0x0 bits 0x40/0x40 rrc: 3 type: IBT flags: 0x408480010000 nid: local remote: 0x76683b3d6040c693 expref: -99 pid: 6682 timeout: 0 lvb_type: 0
00000008:00010000:0.0:1560698103.491006:0:12953:0:(osc_cache.c:1113:osc_extent_make_ready()) ### extent: ffff9089f89e2a50 ns: lustre-MDT0000-mdc-ffff90897640f000 lock: ffff9089ec0ee000/0xeb72e01621e5d8a8 lrc: 4/0,0 mode: PW/PW res: [0x200000403:0x1350:0x0].0x0 bits 0x40/0x40 rrc: 3 type: IBT flags: 0x449480010000 nid: local remote: 0x76683b3d6040c693 expref: -99 pid: 6682 timeout: 0 lvb_type: 0
00000008:00010000:0.0:1560698103.491062:0:12953:0:(osc_cache.c:867:osc_extent_finish()) ### extent: ffff9089f89e2a50 ns: lustre-MDT0000-mdc-ffff90897640f000 lock: ffff9089ec0ee000/0xeb72e01621e5d8a8 lrc: 4/0,0 mode: PW/PW res: [0x200000403:0x1350:0x0].0x0 bits 0x40/0x40 rrc: 3 type: IBT flags: 0x449480010000 nid: local remote: 0x76683b3d6040c693 expref: -99 pid: 6682 timeout: 0 lvb_type: 0
00000008:00010000:0.0:1560698103.491085:0:12953:0:(osc_cache.c:489:__osc_extent_remove()) ### extent: ffff9089f89e2a50 ns: lustre-MDT0000-mdc-ffff90897640f000 lock: ffff9089ec0ee000/0xeb72e01621e5d8a8 lrc: 4/0,0 mode: PW/PW res: [0x200000403:0x1350:0x0].0x0 bits 0x40/0x40 rrc: 3 type: IBT flags: 0x449480010000 nid: local remote: 0x76683b3d6040c693 expref: -99 pid: 6682 timeout: 0 lvb_type: 0
00010000:00010000:0.0:1560698103.491227:0:12953:0:(ldlm_lockd.c:1761:ldlm_handle_bl_callback()) ### client blocking callback handler END ns: lustre-MDT0000-mdc-ffff90897640f000 lock: ffff9089ec0ee000/0xeb72e01621e5d8a8 lrc: 1/0,0 mode: --/PW res: [0x200000403:0x1350:0x0].0x0 bits 0x40/0x40 rrc: 3 type: IBT flags: 0x4c49480010000 nid: local remote: 0x76683b3d6040c693 expref: -99 pid: 6682 timeout: 0 lvb_type: 0
00000008:00020000:0.0:1560698103.551596:0:6682:0:(osc_cache.c:3074:osc_cache_writeback_range()) extent ffff90895c8b7d10@\{[0 -> 255/255], [1|0|-|cache|wiY|ffff90895ea34500], [1703936|192|+|-|ffff90895de79440|256| (null)]}
00000008:00020000:0.0:1560698103.563094:0:6682:0:(osc_cache.c:3074:osc_cache_writeback_range()) ### extent: ffff90895c8b7d10 ns: lustre-OST0000-osc-ffff90897640f000 lock: ffff90895de79440/0xeb72e01621e5d8fc lrc: 2/0,0 mode: PW/PW res: [0x511:0x0:0x0].0x0 rrc: 2 type: EXT [0->18446744073709551615] (req 262144->18446744073709551615) flags: 0x20000020000 nid: local remote: 0x5d533c3e80fa6ceb expref: -99 pid: 6682 timeout: 0 lvb_type: 1
00000008:00020000:0.0:1560698103.579593:0:6682:0:(osc_cache.c:1216:osc_extent_tree_dump0()) Dump object ffff90895ea34500 extents at osc_cache_writeback_range:3074, mppr: 256.
00000008:00020000:0.0:1560698103.586774:0:6682:0:(osc_cache.c:1221:osc_extent_tree_dump0()) extent ffff90895c8b7d10@\{[0 -> 255/255], [1|0|-|cache|wiY|ffff90895ea34500], [1703936|192|+|-|ffff90895de79440|256| (null)]} in tree 1.
00000008:00020000:0.0:1560698103.595536:0:6682:0:(osc_cache.c:1221:osc_extent_tree_dump0()) ### extent: ffff90895c8b7d10 ns: lustre-OST0000-osc-ffff90897640f000 lock: ffff90895de79440/0xeb72e01621e5d8fc lrc: 2/0,0 mode: PW/PW res: [0x511:0x0:0x0].0x0 rrc: 2 type: EXT [0->18446744073709551615] (req 262144->18446744073709551615) flags: 0x20000020000 nid: local remote: 0x5d533c3e80fa6ceb expref: -99 pid: 6682 timeout: 0 lvb_type: 1
00000008:00040000:0.0:1560698103.611993:0:6682:0:(osc_cache.c:3074:osc_cache_writeback_range()) ASSERTION( ext->oe_start >= start && ext->oe_end <= end ) failed:
Ah, good catch, askulysh.
Do you have a thought on how to fix this? I can think of several approaches, but I'm struggling to think what's best.
1. It's not really necessary for the start of the first OSC extent to be chunk aligned, as long as it's smaller than one chunk. (I think?)
2. We could modify the lov code to give a start of zero for the first non-DOM component, but while that would work, it seems wrong - The component does not start at zero.
I like (1), but it would require making the OSC layer aware that it's the first extent. So that would require passing some info down, might be complicated.
tappro, if you have an opinion too... 
Hm, that means we are comparing just different values - extent 'chunks' vs page index, which is wrong obviously. The 'start' and 'end' parameters much be not page index but also in 'chunks' units. Considering that it seems whole osc_cache_writeback_range() is wrong when it checks oe_start/end against start/end parameters, isn't it?
Ah, it is not in chunks but aligned to that, right?
OK, what if we will align start/end inside osc_cache_writeback_range() also by cl_chunkbits before using them?
Oh, that's a good idea! I like that, I'll give it a try.
Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35525
Subject: LU-12462 osc: align writeback to chunk size
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: efa7e2fc1918310b0b0ab7201250719a0c629f40
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35525/
Subject: LU-12462 osc: Do not assert for first extent
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 092ecd66127eade284550b83192fa004ff55501b
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35733/
Subject: LU-12462 osc: layout and chunkbits alignment mismatch
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 7a9f7dec700c5c553396475daad272475f1b20be
Seems like everything has landed for 2.13
Minh Diep (mdiep@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36875
Subject: LU-12462 llite: Remove old fsync versions
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: fbbe0d3c0a12c1d6bbb2f7ac8dbaaf644f43e56c
Minh Diep (mdiep@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36876
Subject: LU-12462 osc: Do not assert for first extent
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: 65fd51a06c3edc9b04d82b172b3ca8a7dea6618c
Minh Diep (mdiep@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36877
Subject: LU-12462 osc: layout and chunkbits alignment mismatch
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: fbffbaf6b55ba928f2f75870a76144d3377e9dc4
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36876/
Subject: LU-12462 osc: Do not assert for first extent
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: c75de5783b6c5104373acbd9be7d4281fb410705
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36877/
Subject: LU-12462 osc: layout and chunkbits alignment mismatch
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 77f11cda573ff7001317c1ca87bffad992d66e25