Metadata writeback cache support
(LU-10938)
|
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Technical task | Priority: | Minor |
| Reporter: | Qian Yingjin | Assignee: | Qian Yingjin |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||
| Rank (Obsolete): | 9223372036854775807 | ||||
| Description |
|
Maloo testing reports the following panic: LustreError: 7:0:(wbc.c:866:wbc_inode_flush_lockdrop()) ASSERTION( !wbc_inode_has_protected(wbci) ) failed: WBC flags: 85 inode 00000000982468e8 [ 1026.402024] LustreError: 7:0:(wbc.c:866:wbc_inode_flush_lockdrop()) LBUG [ 1026.404520] Pid: 7, comm: kworker/u4:0 4.18.0-240.22.1.el8_3.x86_64 #1 SMP Thu Apr 8 19:01:30 UTC 2021 [ 1026.407533] Call Trace TBD: [ 1026.408826] [<0>] libcfs_call_trace+0x6f/0x90 [libcfs] [ 1026.410524] [<0>] lbug_with_loc+0x43/0x80 [libcfs] [ 1026.412388] [<0>] wbc_inode_flush_lockdrop+0xed/0xf0 [lustre] [ 1026.414304] [<0>] wbc_write_inode+0x184/0x1a0 [lustre] [ 1026.416076] [<0>] __writeback_single_inode+0x2da/0x370 [ 1026.417803] [<0>] writeback_sb_inodes+0x1e7/0x440 [ 1026.419369] [<0>] __writeback_inodes_wb+0x5f/0xc0 [ 1026.420905] [<0>] wb_writeback+0x25b/0x2f0 [ 1026.422171] [<0>] wb_workfn+0x192/0x4a0 [ 1026.423350] [<0>] process_one_work+0x1a7/0x360 [ 1026.424651] [<0>] worker_thread+0x30/0x390 [ 1026.425884] [<0>] kthread+0x112/0x130 [ 1026.427060] [<0>] ret_from_fork+0x35/0x40 [ 1026.428258] Kernel panic - not syncing: LBUG The panic is introduced by. a write followed a sync call.
writeback_sb_inodes()
if ((inode->i_state & I_SYNC) && wbc.sync_mode != WB_SYNC_ALL) {
/*
* If this inode is locked for writeback and we are not
* doing writeback-for-data-integrity, move it to
* b_more_io so that writeback can proceed with the
* other inodes on s_io.
*
* We'll have another go at writing back this inode
* when we completed a full scan of b_io.
*/
spin_unlock(&inode->i_lock);
requeue_io(inode, wb);
trace_writeback_sb_inodes_requeue(inode);
continue;
}
When kernel is flushing the parent inode P (with I_SYNC flags), sync with WB_SYNC_NONE (in the sync call context) will skip this inode, move it to b_more_io so that writeback can proceed with the other inodes on s_io. However, if the parent inode is not flushed to the server, we can not flush the children inodes under the directory. This is the reason that triggers the panic. |
| Comments |
| Comment by Gerrit Updater [ 28/Jul/21 ] |
|
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/44408 |