[oops, 4.4-rc8] warn + oops during generic/204

[oops, 4.4-rc8] warn + oops during generic/204

[Dave Chinner]

Hi f2fs folks,

I just ran xfstests on f2fs using defaults and a pair of 4GB ram
disks for the test and scratch devices, and it hard locked the
machine with this failure in generic/204:

[  125.141471] run fstests generic/204 at 2016-01-21 08:24:22
[  127.582183] ------------[ cut here ]------------
[  127.583225] WARNING: CPU: 10 PID: 1224 at fs/f2fs/segment.c:916 new_curseg+0x296/0x380()
[  127.584904] Modules linked in:
[  127.585558] CPU: 10 PID: 1224 Comm: kworker/u32:3 Not tainted 4.4.0-rc8-dgc+ #631
[  127.587057] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[  127.589329] Workqueue: writeback wb_workfn (flush-1:1)
[  127.590966]  ffffffff82251760 ffff88042a163888 ffffffff817a25b9 0000000000000000
[  127.593762]  ffff88042a1638c0 ffffffff810aa006 0000000000000002 0000000000000001
[  127.596839]  ffff8804260e1800 000000000000002d ffff880429e4a800 ffff88042a1638d0
[  127.599825] Call Trace:
[  127.600832]  [<ffffffff817a25b9>] dump_stack+0x4b/0x72
[  127.602821]  [<ffffffff810aa006>] warn_slowpath_common+0x86/0xc0
[  127.605184]  [<ffffffff810aa0fa>] warn_slowpath_null+0x1a/0x20
[  127.607337]  [<ffffffff816ee4b6>] new_curseg+0x296/0x380
[  127.608980]  [<ffffffff816ee91d>] allocate_segment_by_default+0x1dd/0x1e0
[  127.611439]  [<ffffffff816eec6d>] allocate_data_block+0x15d/0x2e0
[  127.613590]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
[  127.615503]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
[  127.617443]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
[  127.619483]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
[  127.621388]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
[  127.623451]  [<ffffffff811941c1>] do_writepages+0x21/0x30
[  127.625205]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
[  127.627304]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
[  127.629214]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
[  127.630862]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
[  127.632464]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
[  127.634289]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
[  127.636069]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
[  127.637877]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
[  127.639569]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
[  127.641284]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
[  127.642925]  [<ffffffff810c7176>] kthread+0xe6/0x100
[  127.644325]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
[  127.646032]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
[  127.647504]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
[  127.649285] ---[ end trace 2107b831b703fa3a ]---
[  127.650532] ------------[ cut here ]------------
[  127.651780] WARNING: CPU: 10 PID: 1224 at fs/f2fs/segment.c:955 new_curseg+0x358/0x380()
[  127.653918] Modules linked in:
[  127.654752] CPU: 10 PID: 1224 Comm: kworker/u32:3 Tainted: G        W       4.4.0-rc8-dgc+ #631
[  127.657046] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[  127.659372] Workqueue: writeback wb_workfn (flush-1:1)
[  127.660791]  ffffffff82251760 ffff88042a163888 ffffffff817a25b9 0000000000000000
[  127.662825]  ffff88042a1638c0 ffffffff810aa006 000000000000002d 0000000000000001
[  127.664791]  ffff8804260e1800 ffff880429e4a800 ffff8804260e1800 ffff88042a1638d0
[  127.666679] Call Trace:
[  127.667287]  [<ffffffff817a25b9>] dump_stack+0x4b/0x72
[  127.668562]  [<ffffffff810aa006>] warn_slowpath_common+0x86/0xc0
[  127.670025]  [<ffffffff810aa0fa>] warn_slowpath_null+0x1a/0x20
[  127.671455]  [<ffffffff816ee578>] new_curseg+0x358/0x380
[  127.672761]  [<ffffffff816ee91d>] allocate_segment_by_default+0x1dd/0x1e0
[  127.674397]  [<ffffffff816eec6d>] allocate_data_block+0x15d/0x2e0
[  127.675918]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
[  127.677254]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
[  127.678510]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
[  127.679930]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
[  127.681264]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
[  127.682729]  [<ffffffff811941c1>] do_writepages+0x21/0x30
[  127.684009]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
[  127.685532]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
[  127.686913]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
[  127.688223]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
[  127.689370]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
[  127.690696]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
[  127.692054]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
[  127.693361]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
[  127.694569]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
[  127.695905]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
[  127.697110]  [<ffffffff810c7176>] kthread+0xe6/0x100
[  127.698083]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
[  127.699388]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
[  127.700484]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
[  127.701743] ---[ end trace 2107b831b703fa3b ]---
[  127.702644] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  127.704234] IP: [<ffffffff816ec3d8>] update_sit_entry+0xe8/0x270
[  127.705434] PGD 0 
[  127.705859] Oops: 0000 [#1] PREEMPT SMP 
[  127.706687] Modules linked in:
[  127.707323] CPU: 10 PID: 1224 Comm: kworker/u32:3 Tainted: G        W       4.4.0-rc8-dgc+ #631
[  127.709037] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[  127.710743] Workqueue: writeback wb_workfn (flush-1:1)
[  127.711798] task: ffff88042a144580 ti: ffff88042a160000 task.ti: ffff88042a160000
[  127.713260] RIP: 0010:[<ffffffff816ec3d8>]  [<ffffffff816ec3d8>] update_sit_entry+0xe8/0x270
[  127.714921] RSP: 0018:ffff88042a163908  EFLAGS: 00010202
[  127.715952] RAX: 0000000000000000 RBX: ffff8804260e1800 RCX: 0000000000000007
[  127.717389] RDX: ffff8800ba868540 RSI: 0000000000000000 RDI: 0000000000000001
[  127.718768] RBP: ffff88042a163948 R08: ffff88042a163a19 R09: ffff880429e4a800
[  127.720157] R10: 0000000000000000 R11: ffff8800ba8680c0 R12: ffff8800bb1849d8
[  127.721530] R13: 0000000000000080 R14: 0000000000000001 R15: 000000000000002d
[  127.722902] FS:  0000000000000000(0000) GS:ffff88043fd40000(0000) knlGS:0000000000000000
[  127.724469] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  127.725579] CR2: 0000000000000000 CR3: 0000000002371000 CR4: 00000000000006e0
[  127.726961] Stack:
[  127.727376]  0000002dbb00f980 ffff8800ba868540 0000000000000000 ffff8804260e1800
[  127.728892]  0000000000006a00 0000000000003e40 ffff8800bb00f980 0000000000000004
[  127.730411]  ffff88042a163970 ffffffff816edd94 0000000000000180 ffff8804260e1800
[  127.731918] Call Trace:
[  127.732403]  [<ffffffff816edd94>] refresh_sit_entry+0x24/0xc0
[  127.733539]  [<ffffffff816eec7e>] allocate_data_block+0x16e/0x2e0
[  127.734724]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
[  127.735810]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
[  127.736898]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
[  127.738103]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
[  127.739241]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
[  127.740462]  [<ffffffff811941c1>] do_writepages+0x21/0x30
[  127.741520]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
[  127.742787]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
[  127.743977]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
[  127.745063]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
[  127.746070]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
[  127.747245]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
[  127.748469]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
[  127.749472]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
[  127.750419]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
[  127.751429]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
[  127.752464]  [<ffffffff810c7176>] kthread+0xe6/0x100
[  127.753324]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
[  127.754449]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
[  127.755384]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
[  127.756513] Code: 44 24 30 48 8b 53 38 48 8b 12 48 89 82 a8 00 00 00 44 89 e8 41 bd 01 00 00 00 c1 e8 03 41 d3 e5 48 89 c6 49 03 74 24 08 45 85 f6 <0f> be 16 0f 8e  
[  127.760859] RIP  [<ffffffff816ec3d8>] update_sit_entry+0xe8/0x270
[  127.761929]  RSP <ffff88042a163908>
[  127.762537] CR2: 0000000000000000
[  127.763118] ---[ end trace 2107b831b703fa3c ]---

It's completely repeatable.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

Re: [oops, 4.4-rc8] warn + oops during generic/204

[Chao Yu]

Hi Dave,

> -----Original Message-----
> From: Dave Chinner [mailto:david@fromorbit.com]
> Sent: Thursday, January 21, 2016 5:31 AM
> To: linux-f2fs-devel@lists.sourceforge.net
> Subject: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> 
> Hi f2fs folks,
> 
> I just ran xfstests on f2fs using defaults and a pair of 4GB ram
> disks for the test and scratch devices, and it hard locked the
> machine with this failure in generic/204:

Thanks for your report! :)

Hi all,

We didn't handle well with the case of inline data storm which floods
full disk. Actually the reason is: if we have 10M free space, and user
fillings the disk with ~10M inline data, then in memory there are ~10M
dirty inline datas and ~10M dirty inodes, once inodes were writebacked
before inline datas, all free space will be occupied, then we have to
write these dirty inline datas to ovp area which doesn't have enough
space there normally.

IMO, one solution could be: when writebacking node pages, we could
verify the number of dirty inline data pages, if there are too many of
them (which may potentially cause running out of free space), merging
data of inline pages into inode pages with enough number.

Or better ideas? :)

---
 fs/f2fs/checkpoint.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
 fs/f2fs/f2fs.h       |  6 +++++-
 fs/f2fs/inline.c     |  3 +++
 fs/f2fs/segment.c    |  3 +++
 fs/f2fs/segment.h    |  9 +++++++++
 5 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index c75b148..b95deb1 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -844,6 +844,55 @@ retry:
 	goto retry;
 }
 
+int sync_inline_inode_page(struct f2fs_sb_info *sbi)
+{
+	struct list_head *head;
+	struct inode *inode;
+	struct f2fs_inode_info *fi;
+
+retry:
+	if (!get_pages(sbi, F2FS_DIRTY_INLINE))
+		return 0;
+
+	if (!has_inline_data_exceeded(sbi))
+		return 0;
+
+	if (unlikely(f2fs_cp_error(sbi)))
+		return -EIO;
+
+	spin_lock(&sbi->inode_lock[FILE_INODE]);
+	head = &sbi->inode_list[FILE_INODE];
+	if (list_empty(head)) {
+		spin_unlock(&sbi->inode_lock[FILE_INODE]);
+		return 0;
+	}
+
+	fi = list_entry(head->next, struct f2fs_inode_info, dirty_list);
+	inode = igrab(&fi->vfs_inode);
+	spin_unlock(&sbi->inode_lock[FILE_INODE]);
+
+	if (inode) {
+		if (f2fs_has_inline_data(inode))
+			filemap_fdatawrite(inode->i_mapping);
+
+		spin_lock(&sbi->inode_lock[FILE_INODE]);
+		if (is_inode_flag_set(fi, FI_DIRTY_FILE))
+			list_move_tail(&fi->dirty_list,
+					&sbi->inode_list[FILE_INODE]);
+		spin_unlock(&sbi->inode_lock[FILE_INODE]);
+
+		iput(inode);
+	} else {
+		/*
+		 * We should submit bio, since it exists several
+		 * wribacking dentry pages in the freeing inode.
+		 */
+		f2fs_submit_merged_bio(sbi, DATA, WRITE);
+		cond_resched();
+	}
+	goto retry;
+}
+
 /*
  * Freeze all the FS-operations for checkpoint.
  */
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 456e478..dc7f679 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -654,6 +654,7 @@ enum count_type {
 	F2FS_WRITEBACK,
 	F2FS_DIRTY_DENTS,
 	F2FS_DIRTY_DATA,
+	F2FS_DIRTY_INLINE,
 	F2FS_DIRTY_NODES,
 	F2FS_DIRTY_META,
 	F2FS_INMEM_PAGES,
@@ -1103,12 +1104,14 @@ static inline void inc_page_count(struct f2fs_sb_info *sbi, int count_type)
 	atomic_inc(&sbi->nr_pages[count_type]);
 	set_sbi_flag(sbi, SBI_IS_DIRTY);
 }
-
+static inline int f2fs_has_inline_data(struct inode *inode);
 static inline void inode_inc_dirty_pages(struct inode *inode)
 {
 	atomic_inc(&F2FS_I(inode)->dirty_pages);
 	inc_page_count(F2FS_I_SB(inode), S_ISDIR(inode->i_mode) ?
 				F2FS_DIRTY_DENTS : F2FS_DIRTY_DATA);
+	if (f2fs_has_inline_data(inode))
+		inc_page_count(F2FS_I_SB(inode), F2FS_DIRTY_INLINE);
 }
 
 static inline void dec_page_count(struct f2fs_sb_info *sbi, int count_type)
@@ -1875,6 +1878,7 @@ void update_dirty_page(struct inode *, struct page *);
 void add_dirty_dir_inode(struct inode *);
 void remove_dirty_inode(struct inode *);
 int sync_dirty_inodes(struct f2fs_sb_info *, enum inode_type);
+int sync_inline_inode_page(struct f2fs_sb_info *);
 int write_checkpoint(struct f2fs_sb_info *, struct cp_control *);
 void init_ino_entry_info(struct f2fs_sb_info *);
 int __init create_checkpoint_caches(void);
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index c3f0b7d..2b3068b 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -162,6 +162,7 @@ no_update:
 clear_out:
 	stat_dec_inline_inode(dn->inode);
 	f2fs_clear_inline_inode(dn->inode);
+	dec_page_count(F2FS_I_SB(dn->inode), F2FS_DIRTY_INLINE);
 	sync_inode_page(dn);
 	f2fs_put_dnode(dn);
 	return 0;
@@ -232,6 +233,8 @@ int f2fs_write_inline_data(struct inode *inode, struct page *page)
 	set_inode_flag(F2FS_I(inode), FI_APPEND_WRITE);
 	set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
 
+	dec_page_count(F2FS_I_SB(inode), F2FS_DIRTY_INLINE);
+
 	sync_inode_page(&dn);
 	f2fs_put_dnode(&dn);
 	return 0;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 070988b..9dbd748 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -290,6 +290,9 @@ void f2fs_balance_fs_bg(struct f2fs_sb_info *sbi)
 	if (!available_free_memory(sbi, FREE_NIDS))
 		try_to_free_nids(sbi, NAT_ENTRY_PER_BLOCK * FREE_NID_PAGES);
 
+	/* sync dirty pages of inline inode to inode page */
+	sync_inline_inode_page(sbi);
+
 	/* checkpoint is the only way to shrink partial cached entries */
 	if (!available_free_memory(sbi, NAT_ENTRIES) ||
 			!available_free_memory(sbi, INO_ENTRIES) ||
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index ee44d34..e0d984dd 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -482,6 +482,15 @@ static inline bool has_not_enough_free_secs(struct f2fs_sb_info *sbi, int freed)
 						reserved_sections(sbi));
 }
 
+static inline bool has_inline_data_exceeded(struct f2fs_sb_info *sbi)
+{
+	int node_secs = get_blocktype_secs(sbi, F2FS_DIRTY_NODES);
+	int dent_secs = get_blocktype_secs(sbi, F2FS_DIRTY_DENTS);
+	int inline_secs = get_blocktype_secs(sbi, F2FS_DIRTY_INLINE);
+
+	return free_sections(sbi) <= (node_secs + 2 * dent_secs + inline_secs);
+}
+
 static inline bool excess_prefree_segs(struct f2fs_sb_info *sbi)
 {
 	return prefree_segments(sbi) > SM_I(sbi)->rec_prefree_segments;
-- 
2.7.0.2.g1b0b6dd

Thanks,

> 
> [  125.141471] run fstests generic/204 at 2016-01-21 08:24:22
> [  127.582183] ------------[ cut here ]------------
> [  127.583225] WARNING: CPU: 10 PID: 1224 at fs/f2fs/segment.c:916 new_curseg+0x296/0x380()
> [  127.584904] Modules linked in:
> [  127.585558] CPU: 10 PID: 1224 Comm: kworker/u32:3 Not tainted 4.4.0-rc8-dgc+ #631
> [  127.587057] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1
> 04/01/2014
> [  127.589329] Workqueue: writeback wb_workfn (flush-1:1)
> [  127.590966]  ffffffff82251760 ffff88042a163888 ffffffff817a25b9 0000000000000000
> [  127.593762]  ffff88042a1638c0 ffffffff810aa006 0000000000000002 0000000000000001
> [  127.596839]  ffff8804260e1800 000000000000002d ffff880429e4a800 ffff88042a1638d0
> [  127.599825] Call Trace:
> [  127.600832]  [<ffffffff817a25b9>] dump_stack+0x4b/0x72
> [  127.602821]  [<ffffffff810aa006>] warn_slowpath_common+0x86/0xc0
> [  127.605184]  [<ffffffff810aa0fa>] warn_slowpath_null+0x1a/0x20
> [  127.607337]  [<ffffffff816ee4b6>] new_curseg+0x296/0x380
> [  127.608980]  [<ffffffff816ee91d>] allocate_segment_by_default+0x1dd/0x1e0
> [  127.611439]  [<ffffffff816eec6d>] allocate_data_block+0x15d/0x2e0
> [  127.613590]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
> [  127.615503]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
> [  127.617443]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
> [  127.619483]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
> [  127.621388]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
> [  127.623451]  [<ffffffff811941c1>] do_writepages+0x21/0x30
> [  127.625205]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
> [  127.627304]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
> [  127.629214]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
> [  127.630862]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
> [  127.632464]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
> [  127.634289]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
> [  127.636069]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
> [  127.637877]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
> [  127.639569]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.641284]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.642925]  [<ffffffff810c7176>] kthread+0xe6/0x100
> [  127.644325]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.646032]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
> [  127.647504]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.649285] ---[ end trace 2107b831b703fa3a ]---
> [  127.650532] ------------[ cut here ]------------
> [  127.651780] WARNING: CPU: 10 PID: 1224 at fs/f2fs/segment.c:955 new_curseg+0x358/0x380()
> [  127.653918] Modules linked in:
> [  127.654752] CPU: 10 PID: 1224 Comm: kworker/u32:3 Tainted: G        W       4.4.0-rc8-dgc+
> #631
> [  127.657046] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1
> 04/01/2014
> [  127.659372] Workqueue: writeback wb_workfn (flush-1:1)
> [  127.660791]  ffffffff82251760 ffff88042a163888 ffffffff817a25b9 0000000000000000
> [  127.662825]  ffff88042a1638c0 ffffffff810aa006 000000000000002d 0000000000000001
> [  127.664791]  ffff8804260e1800 ffff880429e4a800 ffff8804260e1800 ffff88042a1638d0
> [  127.666679] Call Trace:
> [  127.667287]  [<ffffffff817a25b9>] dump_stack+0x4b/0x72
> [  127.668562]  [<ffffffff810aa006>] warn_slowpath_common+0x86/0xc0
> [  127.670025]  [<ffffffff810aa0fa>] warn_slowpath_null+0x1a/0x20
> [  127.671455]  [<ffffffff816ee578>] new_curseg+0x358/0x380
> [  127.672761]  [<ffffffff816ee91d>] allocate_segment_by_default+0x1dd/0x1e0
> [  127.674397]  [<ffffffff816eec6d>] allocate_data_block+0x15d/0x2e0
> [  127.675918]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
> [  127.677254]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
> [  127.678510]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
> [  127.679930]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
> [  127.681264]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
> [  127.682729]  [<ffffffff811941c1>] do_writepages+0x21/0x30
> [  127.684009]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
> [  127.685532]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
> [  127.686913]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
> [  127.688223]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
> [  127.689370]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
> [  127.690696]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
> [  127.692054]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
> [  127.693361]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
> [  127.694569]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.695905]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.697110]  [<ffffffff810c7176>] kthread+0xe6/0x100
> [  127.698083]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.699388]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
> [  127.700484]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.701743] ---[ end trace 2107b831b703fa3b ]---
> [  127.702644] BUG: unable to handle kernel NULL pointer dereference at           (null)
> [  127.704234] IP: [<ffffffff816ec3d8>] update_sit_entry+0xe8/0x270
> [  127.705434] PGD 0
> [  127.705859] Oops: 0000 [#1] PREEMPT SMP
> [  127.706687] Modules linked in:
> [  127.707323] CPU: 10 PID: 1224 Comm: kworker/u32:3 Tainted: G        W       4.4.0-rc8-dgc+
> #631
> [  127.709037] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1
> 04/01/2014
> [  127.710743] Workqueue: writeback wb_workfn (flush-1:1)
> [  127.711798] task: ffff88042a144580 ti: ffff88042a160000 task.ti: ffff88042a160000
> [  127.713260] RIP: 0010:[<ffffffff816ec3d8>]  [<ffffffff816ec3d8>]
> update_sit_entry+0xe8/0x270
> [  127.714921] RSP: 0018:ffff88042a163908  EFLAGS: 00010202
> [  127.715952] RAX: 0000000000000000 RBX: ffff8804260e1800 RCX: 0000000000000007
> [  127.717389] RDX: ffff8800ba868540 RSI: 0000000000000000 RDI: 0000000000000001
> [  127.718768] RBP: ffff88042a163948 R08: ffff88042a163a19 R09: ffff880429e4a800
> [  127.720157] R10: 0000000000000000 R11: ffff8800ba8680c0 R12: ffff8800bb1849d8
> [  127.721530] R13: 0000000000000080 R14: 0000000000000001 R15: 000000000000002d
> [  127.722902] FS:  0000000000000000(0000) GS:ffff88043fd40000(0000) knlGS:0000000000000000
> [  127.724469] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  127.725579] CR2: 0000000000000000 CR3: 0000000002371000 CR4: 00000000000006e0
> [  127.726961] Stack:
> [  127.727376]  0000002dbb00f980 ffff8800ba868540 0000000000000000 ffff8804260e1800
> [  127.728892]  0000000000006a00 0000000000003e40 ffff8800bb00f980 0000000000000004
> [  127.730411]  ffff88042a163970 ffffffff816edd94 0000000000000180 ffff8804260e1800
> [  127.731918] Call Trace:
> [  127.732403]  [<ffffffff816edd94>] refresh_sit_entry+0x24/0xc0
> [  127.733539]  [<ffffffff816eec7e>] allocate_data_block+0x16e/0x2e0
> [  127.734724]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
> [  127.735810]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
> [  127.736898]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
> [  127.738103]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
> [  127.739241]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
> [  127.740462]  [<ffffffff811941c1>] do_writepages+0x21/0x30
> [  127.741520]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
> [  127.742787]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
> [  127.743977]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
> [  127.745063]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
> [  127.746070]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
> [  127.747245]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
> [  127.748469]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
> [  127.749472]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
> [  127.750419]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.751429]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.752464]  [<ffffffff810c7176>] kthread+0xe6/0x100
> [  127.753324]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.754449]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
> [  127.755384]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.756513] Code: 44 24 30 48 8b 53 38 48 8b 12 48 89 82 a8 00 00 00 44 89 e8 41 bd 01 00
> 00 00 c1 e8 03 41 d3 e5 48 89 c6 49 03 74 24 08 45 85 f6 <0f> be 16 0f 8e
> [  127.760859] RIP  [<ffffffff816ec3d8>] update_sit_entry+0xe8/0x270
> [  127.761929]  RSP <ffff88042a163908>
> [  127.762537] CR2: 0000000000000000
> [  127.763118] ---[ end trace 2107b831b703fa3c ]---
> 
> It's completely repeatable.
> 
> Cheers,
> 
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

Re: [oops, 4.4-rc8] warn + oops during generic/204

[Jaegeuk Kim]

Hi Dave,

Thank you for pointing this out.
Actually I turned off 204 in my test cases, so I couldn't get this before.

I think mkfs.f2fs calculates the number of blocks for users incorrectly.
Let us investigate and resolve this issue.

Thanks,

On Thu, Jan 21, 2016 at 08:31:02AM +1100, Dave Chinner wrote:
> Hi f2fs folks,
> 
> I just ran xfstests on f2fs using defaults and a pair of 4GB ram
> disks for the test and scratch devices, and it hard locked the
> machine with this failure in generic/204:
> 
> [  125.141471] run fstests generic/204 at 2016-01-21 08:24:22
> [  127.582183] ------------[ cut here ]------------
> [  127.583225] WARNING: CPU: 10 PID: 1224 at fs/f2fs/segment.c:916 new_curseg+0x296/0x380()
> [  127.584904] Modules linked in:
> [  127.585558] CPU: 10 PID: 1224 Comm: kworker/u32:3 Not tainted 4.4.0-rc8-dgc+ #631
> [  127.587057] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
> [  127.589329] Workqueue: writeback wb_workfn (flush-1:1)
> [  127.590966]  ffffffff82251760 ffff88042a163888 ffffffff817a25b9 0000000000000000
> [  127.593762]  ffff88042a1638c0 ffffffff810aa006 0000000000000002 0000000000000001
> [  127.596839]  ffff8804260e1800 000000000000002d ffff880429e4a800 ffff88042a1638d0
> [  127.599825] Call Trace:
> [  127.600832]  [<ffffffff817a25b9>] dump_stack+0x4b/0x72
> [  127.602821]  [<ffffffff810aa006>] warn_slowpath_common+0x86/0xc0
> [  127.605184]  [<ffffffff810aa0fa>] warn_slowpath_null+0x1a/0x20
> [  127.607337]  [<ffffffff816ee4b6>] new_curseg+0x296/0x380
> [  127.608980]  [<ffffffff816ee91d>] allocate_segment_by_default+0x1dd/0x1e0
> [  127.611439]  [<ffffffff816eec6d>] allocate_data_block+0x15d/0x2e0
> [  127.613590]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
> [  127.615503]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
> [  127.617443]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
> [  127.619483]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
> [  127.621388]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
> [  127.623451]  [<ffffffff811941c1>] do_writepages+0x21/0x30
> [  127.625205]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
> [  127.627304]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
> [  127.629214]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
> [  127.630862]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
> [  127.632464]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
> [  127.634289]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
> [  127.636069]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
> [  127.637877]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
> [  127.639569]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.641284]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.642925]  [<ffffffff810c7176>] kthread+0xe6/0x100
> [  127.644325]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.646032]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
> [  127.647504]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.649285] ---[ end trace 2107b831b703fa3a ]---
> [  127.650532] ------------[ cut here ]------------
> [  127.651780] WARNING: CPU: 10 PID: 1224 at fs/f2fs/segment.c:955 new_curseg+0x358/0x380()
> [  127.653918] Modules linked in:
> [  127.654752] CPU: 10 PID: 1224 Comm: kworker/u32:3 Tainted: G        W       4.4.0-rc8-dgc+ #631
> [  127.657046] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
> [  127.659372] Workqueue: writeback wb_workfn (flush-1:1)
> [  127.660791]  ffffffff82251760 ffff88042a163888 ffffffff817a25b9 0000000000000000
> [  127.662825]  ffff88042a1638c0 ffffffff810aa006 000000000000002d 0000000000000001
> [  127.664791]  ffff8804260e1800 ffff880429e4a800 ffff8804260e1800 ffff88042a1638d0
> [  127.666679] Call Trace:
> [  127.667287]  [<ffffffff817a25b9>] dump_stack+0x4b/0x72
> [  127.668562]  [<ffffffff810aa006>] warn_slowpath_common+0x86/0xc0
> [  127.670025]  [<ffffffff810aa0fa>] warn_slowpath_null+0x1a/0x20
> [  127.671455]  [<ffffffff816ee578>] new_curseg+0x358/0x380
> [  127.672761]  [<ffffffff816ee91d>] allocate_segment_by_default+0x1dd/0x1e0
> [  127.674397]  [<ffffffff816eec6d>] allocate_data_block+0x15d/0x2e0
> [  127.675918]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
> [  127.677254]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
> [  127.678510]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
> [  127.679930]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
> [  127.681264]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
> [  127.682729]  [<ffffffff811941c1>] do_writepages+0x21/0x30
> [  127.684009]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
> [  127.685532]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
> [  127.686913]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
> [  127.688223]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
> [  127.689370]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
> [  127.690696]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
> [  127.692054]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
> [  127.693361]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
> [  127.694569]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.695905]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.697110]  [<ffffffff810c7176>] kthread+0xe6/0x100
> [  127.698083]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.699388]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
> [  127.700484]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.701743] ---[ end trace 2107b831b703fa3b ]---
> [  127.702644] BUG: unable to handle kernel NULL pointer dereference at           (null)
> [  127.704234] IP: [<ffffffff816ec3d8>] update_sit_entry+0xe8/0x270
> [  127.705434] PGD 0 
> [  127.705859] Oops: 0000 [#1] PREEMPT SMP 
> [  127.706687] Modules linked in:
> [  127.707323] CPU: 10 PID: 1224 Comm: kworker/u32:3 Tainted: G        W       4.4.0-rc8-dgc+ #631
> [  127.709037] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
> [  127.710743] Workqueue: writeback wb_workfn (flush-1:1)
> [  127.711798] task: ffff88042a144580 ti: ffff88042a160000 task.ti: ffff88042a160000
> [  127.713260] RIP: 0010:[<ffffffff816ec3d8>]  [<ffffffff816ec3d8>] update_sit_entry+0xe8/0x270
> [  127.714921] RSP: 0018:ffff88042a163908  EFLAGS: 00010202
> [  127.715952] RAX: 0000000000000000 RBX: ffff8804260e1800 RCX: 0000000000000007
> [  127.717389] RDX: ffff8800ba868540 RSI: 0000000000000000 RDI: 0000000000000001
> [  127.718768] RBP: ffff88042a163948 R08: ffff88042a163a19 R09: ffff880429e4a800
> [  127.720157] R10: 0000000000000000 R11: ffff8800ba8680c0 R12: ffff8800bb1849d8
> [  127.721530] R13: 0000000000000080 R14: 0000000000000001 R15: 000000000000002d
> [  127.722902] FS:  0000000000000000(0000) GS:ffff88043fd40000(0000) knlGS:0000000000000000
> [  127.724469] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  127.725579] CR2: 0000000000000000 CR3: 0000000002371000 CR4: 00000000000006e0
> [  127.726961] Stack:
> [  127.727376]  0000002dbb00f980 ffff8800ba868540 0000000000000000 ffff8804260e1800
> [  127.728892]  0000000000006a00 0000000000003e40 ffff8800bb00f980 0000000000000004
> [  127.730411]  ffff88042a163970 ffffffff816edd94 0000000000000180 ffff8804260e1800
> [  127.731918] Call Trace:
> [  127.732403]  [<ffffffff816edd94>] refresh_sit_entry+0x24/0xc0
> [  127.733539]  [<ffffffff816eec7e>] allocate_data_block+0x16e/0x2e0
> [  127.734724]  [<ffffffff816eefad>] do_write_page+0x1bd/0x280
> [  127.735810]  [<ffffffff816ef0f3>] write_node_page+0x23/0x30
> [  127.736898]  [<ffffffff816e7ce5>] f2fs_write_node_page+0x125/0x240
> [  127.738103]  [<ffffffff816e9b31>] sync_node_pages+0x401/0x600
> [  127.739241]  [<ffffffff816e9e38>] f2fs_write_node_pages+0x108/0x130
> [  127.740462]  [<ffffffff811941c1>] do_writepages+0x21/0x30
> [  127.741520]  [<ffffffff811feb25>] __writeback_single_inode+0x45/0x330
> [  127.742787]  [<ffffffff811ff2bb>] writeback_sb_inodes+0x25b/0x4d0
> [  127.743977]  [<ffffffff811ff788>] wb_writeback+0xf8/0x2d0
> [  127.745063]  [<ffffffff8120251e>] wb_workfn+0xfe/0x3b0
> [  127.746070]  [<ffffffff81dcba7e>] ? _raw_spin_unlock_irq+0xe/0x30
> [  127.747245]  [<ffffffff810cedfb>] ? finish_task_switch+0x8b/0x220
> [  127.748469]  [<ffffffff810c17ce>] process_one_work+0x14e/0x410
> [  127.749472]  [<ffffffff810c1dde>] worker_thread+0x4e/0x460
> [  127.750419]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.751429]  [<ffffffff810c1d90>] ? rescuer_thread+0x300/0x300
> [  127.752464]  [<ffffffff810c7176>] kthread+0xe6/0x100
> [  127.753324]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.754449]  [<ffffffff81dcc30f>] ret_from_fork+0x3f/0x70
> [  127.755384]  [<ffffffff810c7090>] ? kthread_create_on_node+0x190/0x190
> [  127.756513] Code: 44 24 30 48 8b 53 38 48 8b 12 48 89 82 a8 00 00 00 44 89 e8 41 bd 01 00 00 00 c1 e8 03 41 d3 e5 48 89 c6 49 03 74 24 08 45 85 f6 <0f> be 16 0f 8e  
> [  127.760859] RIP  [<ffffffff816ec3d8>] update_sit_entry+0xe8/0x270
> [  127.761929]  RSP <ffff88042a163908>
> [  127.762537] CR2: 0000000000000000
> [  127.763118] ---[ end trace 2107b831b703fa3c ]---
> 
> It's completely repeatable.
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

Re: [oops, 4.4-rc8] warn + oops during generic/204

[Jaegeuk Kim]

On Thu, Jan 21, 2016 at 07:46:10PM +0800, Chao Yu wrote:
> Hi Dave,
> 
> > -----Original Message-----
> > From: Dave Chinner [mailto:david@fromorbit.com]
> > Sent: Thursday, January 21, 2016 5:31 AM
> > To: linux-f2fs-devel@lists.sourceforge.net
> > Subject: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> > 
> > Hi f2fs folks,
> > 
> > I just ran xfstests on f2fs using defaults and a pair of 4GB ram
> > disks for the test and scratch devices, and it hard locked the
> > machine with this failure in generic/204:
> 
> Thanks for your report! :)
> 
> Hi all,
> 
> We didn't handle well with the case of inline data storm which floods
> full disk. Actually the reason is: if we have 10M free space, and user
> fillings the disk with ~10M inline data, then in memory there are ~10M
> dirty inline datas and ~10M dirty inodes, once inodes were writebacked
> before inline datas, all free space will be occupied, then we have to
> write these dirty inline datas to ovp area which doesn't have enough
> space there normally.

Well, I think the user block count was wrong which is determined by mkfs.f2fs.
When writing inline_data, gc should activate to reclaim the space, but it
seems it couldn't do that cause there is no victim.
So, when taking a look at mkfs, I suspect that the number of total user blocks
does not consider our current segments, which is 6 by default.
IOWs, we gave more blocks to users, which turns out actually gc couldn't get a
victim from them in this case.

I could reproduce this issue, and once I reduced the number by 6 segments,
I could avoid the issue.

Here the change of f2fs-tools.

>From 411166a44009bb138eca937376863e9ce673278a Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk@kernel.org>
Date: Thu, 21 Jan 2016 05:16:37 -0800
Subject: [PATCH] mkfs.f2fs: adjust current segments for total usable blocks

When calculating total number of user blocks, we should reserve the current
segments.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
 mkfs/f2fs_format.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
index 2c81ecc..b25a490 100644
--- a/mkfs/f2fs_format.c
+++ b/mkfs/f2fs_format.c
@@ -474,7 +474,12 @@ static int f2fs_write_check_point_pack(void)
 
 	/* main segments - reserved segments - (node + data segments) */
 	set_cp(free_segment_count, get_sb(segment_count_main) - 6);
-	set_cp(user_block_count, ((get_cp(free_segment_count) + 6 -
+	if (get_cp(free_segment_count) <= get_cp(overprov_segment_count)) {
+		MSG(0, "Error: Too small size\n");
+		goto free_sum_compact;
+	}
+
+	set_cp(user_block_count, ((get_cp(free_segment_count) -
 			get_cp(overprov_segment_count)) * config.blks_per_seg));
 	/* cp page (2), data summaries (1), node summaries (3) */
 	set_cp(cp_pack_total_block_count, 6 + get_sb(cp_payload));
-- 
2.6.3


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

Re: [oops, 4.4-rc8] warn + oops during generic/204

[Chao Yu]

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> Sent: Friday, January 22, 2016 9:53 AM
> To: Chao Yu
> Cc: 'Dave Chinner'; linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> 
> On Thu, Jan 21, 2016 at 07:46:10PM +0800, Chao Yu wrote:
> > Hi Dave,
> >
> > > -----Original Message-----
> > > From: Dave Chinner [mailto:david@fromorbit.com]
> > > Sent: Thursday, January 21, 2016 5:31 AM
> > > To: linux-f2fs-devel@lists.sourceforge.net
> > > Subject: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> > >
> > > Hi f2fs folks,
> > >
> > > I just ran xfstests on f2fs using defaults and a pair of 4GB ram
> > > disks for the test and scratch devices, and it hard locked the
> > > machine with this failure in generic/204:
> >
> > Thanks for your report! :)
> >
> > Hi all,
> >
> > We didn't handle well with the case of inline data storm which floods
> > full disk. Actually the reason is: if we have 10M free space, and user
> > fillings the disk with ~10M inline data, then in memory there are ~10M
> > dirty inline datas and ~10M dirty inodes, once inodes were writebacked
> > before inline datas, all free space will be occupied, then we have to
> > write these dirty inline datas to ovp area which doesn't have enough
> > space there normally.
> 
> Well, I think the user block count was wrong which is determined by mkfs.f2fs.
> When writing inline_data, gc should activate to reclaim the space, but it
> seems it couldn't do that cause there is no victim.
> So, when taking a look at mkfs, I suspect that the number of total user blocks
> does not consider our current segments, which is 6 by default.
> IOWs, we gave more blocks to users, which turns out actually gc couldn't get a
> victim from them in this case.

Hmm, I don't think this could fix similar inline storm issue, I change some
parameters in generic/204 like below patch, and do the test with your patch
based on commit 9b72a388f586 ("f2fs: skip releasing nodes in chindless extent
tree"), oops occurs again, still the same problem. :(

---
 tests/generic/204 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/generic/204 b/tests/generic/204
index 24a2a94..4db1533 100755
--- a/tests/generic/204
+++ b/tests/generic/204
@@ -56,7 +56,7 @@ _scratch_mkfs 2> /dev/null | _filter_mkfs 2> $tmp.mkfs > /dev/null
 # And v4/512 v5/1k xfs don't have enough free inodes, set imaxpct=50 at mkfs
 # time solves this problem.
 [ $FSTYP = "xfs" ] && MKFS_OPTIONS="$MKFS_OPTIONS -l size=7m -i maxpct=50"
-SIZE=`expr 106 \* 1024 \* 1024`
+SIZE=`expr 406 \* 1024 \* 1024`
 
 _scratch_mkfs_sized $SIZE $dbsize 2> /dev/null \
 		| _filter_mkfs 2> $tmp.mkfs > /dev/null
@@ -69,7 +69,7 @@ _scratch_mount
 # work out correctly. Space usages is based 22500 files and 1024 reserved blocks
 # on a 4k block size 256 byte inode size filesystem.
 resv_blks=1024
-space=97920000
+space=397920000
 
 # decrease files for inode size.
 #	22500 * (256 + 4k) = ~97MB
-- 
2.6.3

I traced the details of this issue, we can get some hints with below datas:

steps in this issue:
a) generic/204: submit 22 * 512 inline data
b) f2fs_write_node_pages: f2fs_balance_fs_bg->f2fs_sync_fs
c) f2fs_write_data_pages: write inline data page into inode page
d) f2fs_write_node_pages: persist inode pages


Test #1, mkfs.f2fs: not patched,  generic/204: not patched:
[MAIN: 45(OverProv:23 Resv:16)]
valid user segment = 45 - 23 = 22
	inline data	dentry		node		free segment	prefree+dirty
a)	22		1		22		39		0
b)	22		0		0		18		0
c)	0		0		22		18		0
d)	0		0		4		0		19

Test #2, mkfs.f2fs: patched,  generic/204: not patched:
[MAIN: 45(OverProv:23 Resv:16)]
valid user segment = 45 - 23 - 6 = 16
	inline data	dentry		node		free segment	prefree+dirty
a)	16		1		16		39		0
b)	16		0		0		23		0
c)	0		0		16		23		0
d)	0		0		0		7		16

Test #3, mkfs.f2fs: patched,  generic/204: patched:
[MAIN: 195(OverProv:44 Resv:28)]
valid user segment = 195 - 44 - 6 = 145
	inline data	dentry		node		free segment	prefree+dirty
a)	145		1		145		189		0
b)	145		0		0		45		0
c)	0		0		145		45		0
d)	0		0		99		0		46

Once we arrive step c), we would face the danger, because writebacking
of dirty node page will exhaust free segments, result in oops.
During step c) to step d), inode pages were COWed, prefree will increase,
it's a pity these prefree segments could only be reused after a checkpoint,
however checkpoint needs more free space for flushing dirty nodes, that
also will exhaust free segments, this likes a chicken and egg problem.

Any idea to solve this?

Thanks,

> 
> I could reproduce this issue, and once I reduced the number by 6 segments,
> I could avoid the issue.
> 
> Here the change of f2fs-tools.
> 
> From 411166a44009bb138eca937376863e9ce673278a Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim <jaegeuk@kernel.org>
> Date: Thu, 21 Jan 2016 05:16:37 -0800
> Subject: [PATCH] mkfs.f2fs: adjust current segments for total usable blocks
> 
> When calculating total number of user blocks, we should reserve the current
> segments.
> 
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>  mkfs/f2fs_format.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
> index 2c81ecc..b25a490 100644
> --- a/mkfs/f2fs_format.c
> +++ b/mkfs/f2fs_format.c
> @@ -474,7 +474,12 @@ static int f2fs_write_check_point_pack(void)
> 
>  	/* main segments - reserved segments - (node + data segments) */
>  	set_cp(free_segment_count, get_sb(segment_count_main) - 6);
> -	set_cp(user_block_count, ((get_cp(free_segment_count) + 6 -
> +	if (get_cp(free_segment_count) <= get_cp(overprov_segment_count)) {
> +		MSG(0, "Error: Too small size\n");
> +		goto free_sum_compact;
> +	}
> +
> +	set_cp(user_block_count, ((get_cp(free_segment_count) -
>  			get_cp(overprov_segment_count)) * config.blks_per_seg));
>  	/* cp page (2), data summaries (1), node summaries (3) */
>  	set_cp(cp_pack_total_block_count, 6 + get_sb(cp_payload));
> --
> 2.6.3



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

Re: [oops, 4.4-rc8] warn + oops during generic/204

[Chao Yu]

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> Sent: Friday, January 22, 2016 9:53 AM
> To: Chao Yu
> Cc: 'Dave Chinner'; linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> 
> On Thu, Jan 21, 2016 at 07:46:10PM +0800, Chao Yu wrote:
> > Hi Dave,
> >
> > > -----Original Message-----
> > > From: Dave Chinner [mailto:david@fromorbit.com]
> > > Sent: Thursday, January 21, 2016 5:31 AM
> > > To: linux-f2fs-devel@lists.sourceforge.net
> > > Subject: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> > >
> > > Hi f2fs folks,
> > >
> > > I just ran xfstests on f2fs using defaults and a pair of 4GB ram
> > > disks for the test and scratch devices, and it hard locked the
> > > machine with this failure in generic/204:
> >
> > Thanks for your report! :)
> >
> > Hi all,
> >
> > We didn't handle well with the case of inline data storm which floods
> > full disk. Actually the reason is: if we have 10M free space, and user
> > fillings the disk with ~10M inline data, then in memory there are ~10M
> > dirty inline datas and ~10M dirty inodes, once inodes were writebacked
> > before inline datas, all free space will be occupied, then we have to
> > write these dirty inline datas to ovp area which doesn't have enough
> > space there normally.
> 
> Well, I think the user block count was wrong which is determined by mkfs.f2fs.
> When writing inline_data, gc should activate to reclaim the space, but it
> seems it couldn't do that cause there is no victim.
> So, when taking a look at mkfs, I suspect that the number of total user blocks
> does not consider our current segments, which is 6 by default.
> IOWs, we gave more blocks to users, which turns out actually gc couldn't get a
> victim from them in this case.
> 
> I could reproduce this issue, and once I reduced the number by 6 segments,
> I could avoid the issue.
> 
> Here the change of f2fs-tools.
> 
> From 411166a44009bb138eca937376863e9ce673278a Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim <jaegeuk@kernel.org>
> Date: Thu, 21 Jan 2016 05:16:37 -0800
> Subject: [PATCH] mkfs.f2fs: adjust current segments for total usable blocks
> 
> When calculating total number of user blocks, we should reserve the current
> segments.

generic/015 generic/077 generic/251 will fail after applying this patch,
I haven't look the details though, I suspect it hits "Too small size"
case.

Thanks,

> 
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>  mkfs/f2fs_format.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
> index 2c81ecc..b25a490 100644
> --- a/mkfs/f2fs_format.c
> +++ b/mkfs/f2fs_format.c
> @@ -474,7 +474,12 @@ static int f2fs_write_check_point_pack(void)
> 
>  	/* main segments - reserved segments - (node + data segments) */
>  	set_cp(free_segment_count, get_sb(segment_count_main) - 6);
> -	set_cp(user_block_count, ((get_cp(free_segment_count) + 6 -
> +	if (get_cp(free_segment_count) <= get_cp(overprov_segment_count)) {
> +		MSG(0, "Error: Too small size\n");
> +		goto free_sum_compact;
> +	}
> +
> +	set_cp(user_block_count, ((get_cp(free_segment_count) -
>  			get_cp(overprov_segment_count)) * config.blks_per_seg));
>  	/* cp page (2), data summaries (1), node summaries (3) */
>  	set_cp(cp_pack_total_block_count, 6 + get_sb(cp_payload));
> --
> 2.6.3



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

Re: [oops, 4.4-rc8] warn + oops during generic/204

[Jaegeuk Kim]

Hi Chao,

On Fri, Jan 22, 2016 at 02:15:26PM +0800, Chao Yu wrote:
> > -----Original Message-----
> > From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> > Sent: Friday, January 22, 2016 9:53 AM
> > To: Chao Yu
> > Cc: 'Dave Chinner'; linux-f2fs-devel@lists.sourceforge.net
> > Subject: Re: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> > 
> > On Thu, Jan 21, 2016 at 07:46:10PM +0800, Chao Yu wrote:
> > > Hi Dave,
> > >
> > > > -----Original Message-----
> > > > From: Dave Chinner [mailto:david@fromorbit.com]
> > > > Sent: Thursday, January 21, 2016 5:31 AM
> > > > To: linux-f2fs-devel@lists.sourceforge.net
> > > > Subject: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> > > >
> > > > Hi f2fs folks,
> > > >
> > > > I just ran xfstests on f2fs using defaults and a pair of 4GB ram
> > > > disks for the test and scratch devices, and it hard locked the
> > > > machine with this failure in generic/204:
> > >
> > > Thanks for your report! :)
> > >
> > > Hi all,
> > >
> > > We didn't handle well with the case of inline data storm which floods
> > > full disk. Actually the reason is: if we have 10M free space, and user
> > > fillings the disk with ~10M inline data, then in memory there are ~10M
> > > dirty inline datas and ~10M dirty inodes, once inodes were writebacked
> > > before inline datas, all free space will be occupied, then we have to
> > > write these dirty inline datas to ovp area which doesn't have enough
> > > space there normally.
> > 
> > Well, I think the user block count was wrong which is determined by mkfs.f2fs.
> > When writing inline_data, gc should activate to reclaim the space, but it
> > seems it couldn't do that cause there is no victim.
> > So, when taking a look at mkfs, I suspect that the number of total user blocks
> > does not consider our current segments, which is 6 by default.
> > IOWs, we gave more blocks to users, which turns out actually gc couldn't get a
> > victim from them in this case.
> 
> Hmm, I don't think this could fix similar inline storm issue, I change some
> parameters in generic/204 like below patch, and do the test with your patch
> based on commit 9b72a388f586 ("f2fs: skip releasing nodes in chindless extent
> tree"), oops occurs again, still the same problem. :(

Urg, yes.

> 
> ---
>  tests/generic/204 | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/generic/204 b/tests/generic/204
> index 24a2a94..4db1533 100755
> --- a/tests/generic/204
> +++ b/tests/generic/204
> @@ -56,7 +56,7 @@ _scratch_mkfs 2> /dev/null | _filter_mkfs 2> $tmp.mkfs > /dev/null
>  # And v4/512 v5/1k xfs don't have enough free inodes, set imaxpct=50 at mkfs
>  # time solves this problem.
>  [ $FSTYP = "xfs" ] && MKFS_OPTIONS="$MKFS_OPTIONS -l size=7m -i maxpct=50"
> -SIZE=`expr 106 \* 1024 \* 1024`
> +SIZE=`expr 406 \* 1024 \* 1024`
>  
>  _scratch_mkfs_sized $SIZE $dbsize 2> /dev/null \
>  		| _filter_mkfs 2> $tmp.mkfs > /dev/null
> @@ -69,7 +69,7 @@ _scratch_mount
>  # work out correctly. Space usages is based 22500 files and 1024 reserved blocks
>  # on a 4k block size 256 byte inode size filesystem.
>  resv_blks=1024
> -space=97920000
> +space=397920000
>  
>  # decrease files for inode size.
>  #	22500 * (256 + 4k) = ~97MB
> -- 
> 2.6.3
> 
> I traced the details of this issue, we can get some hints with below datas:
> 
> steps in this issue:
> a) generic/204: submit 22 * 512 inline data
> b) f2fs_write_node_pages: f2fs_balance_fs_bg->f2fs_sync_fs
> c) f2fs_write_data_pages: write inline data page into inode page
> d) f2fs_write_node_pages: persist inode pages
> 
> 
> Test #1, mkfs.f2fs: not patched,  generic/204: not patched:
> [MAIN: 45(OverProv:23 Resv:16)]
> valid user segment = 45 - 23 = 22
> 	inline data	dentry		node		free segment	prefree+dirty
> a)	22		1		22		39		0
> b)	22		0		0		18		0
> c)	0		0		22		18		0
> d)	0		0		4		0		19
> 
> Test #2, mkfs.f2fs: patched,  generic/204: not patched:
> [MAIN: 45(OverProv:23 Resv:16)]
> valid user segment = 45 - 23 - 6 = 16
> 	inline data	dentry		node		free segment	prefree+dirty
> a)	16		1		16		39		0
> b)	16		0		0		23		0
> c)	0		0		16		23		0
> d)	0		0		0		7		16
> 
> Test #3, mkfs.f2fs: patched,  generic/204: patched:
> [MAIN: 195(OverProv:44 Resv:28)]
> valid user segment = 195 - 44 - 6 = 145
> 	inline data	dentry		node		free segment	prefree+dirty
> a)	145		1		145		189		0
> b)	145		0		0		45		0
> c)	0		0		145		45		0
> d)	0		0		99		0		46
> 
> Once we arrive step c), we would face the danger, because writebacking
> of dirty node page will exhaust free segments, result in oops.
> During step c) to step d), inode pages were COWed, prefree will increase,
> it's a pity these prefree segments could only be reused after a checkpoint,
> however checkpoint needs more free space for flushing dirty nodes, that
> also will exhaust free segments, this likes a chicken and egg problem.
> 
> Any idea to solve this?

One question is why f2fs_gc couldn't make the free space during c).
The answer was there was no victim and no prefree segments, but the dirty node
blocks are producing suddenly.

I wrote two patches regarding to this issue.
Could you check them too?

Thanks,

> 
> Thanks,
> 
> > 
> > I could reproduce this issue, and once I reduced the number by 6 segments,
> > I could avoid the issue.
> > 
> > Here the change of f2fs-tools.
> > 
> > From 411166a44009bb138eca937376863e9ce673278a Mon Sep 17 00:00:00 2001
> > From: Jaegeuk Kim <jaegeuk@kernel.org>
> > Date: Thu, 21 Jan 2016 05:16:37 -0800
> > Subject: [PATCH] mkfs.f2fs: adjust current segments for total usable blocks
> > 
> > When calculating total number of user blocks, we should reserve the current
> > segments.
> > 
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >  mkfs/f2fs_format.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
> > index 2c81ecc..b25a490 100644
> > --- a/mkfs/f2fs_format.c
> > +++ b/mkfs/f2fs_format.c
> > @@ -474,7 +474,12 @@ static int f2fs_write_check_point_pack(void)
> > 
> >  	/* main segments - reserved segments - (node + data segments) */
> >  	set_cp(free_segment_count, get_sb(segment_count_main) - 6);
> > -	set_cp(user_block_count, ((get_cp(free_segment_count) + 6 -
> > +	if (get_cp(free_segment_count) <= get_cp(overprov_segment_count)) {
> > +		MSG(0, "Error: Too small size\n");
> > +		goto free_sum_compact;
> > +	}
> > +
> > +	set_cp(user_block_count, ((get_cp(free_segment_count) -
> >  			get_cp(overprov_segment_count)) * config.blks_per_seg));
> >  	/* cp page (2), data summaries (1), node summaries (3) */
> >  	set_cp(cp_pack_total_block_count, 6 + get_sb(cp_payload));
> > --
> > 2.6.3
> 

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

Re: [oops, 4.4-rc8] warn + oops during generic/204

[Chao Yu]

Hi Jaegeuk,

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> Sent: Sunday, January 24, 2016 4:16 AM
> To: Chao Yu
> Cc: 'Dave Chinner'; linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> 
> Hi Chao,
> 
> On Fri, Jan 22, 2016 at 02:15:26PM +0800, Chao Yu wrote:
> > > -----Original Message-----
> > > From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> > > Sent: Friday, January 22, 2016 9:53 AM
> > > To: Chao Yu
> > > Cc: 'Dave Chinner'; linux-f2fs-devel@lists.sourceforge.net
> > > Subject: Re: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> > >
> > > On Thu, Jan 21, 2016 at 07:46:10PM +0800, Chao Yu wrote:
> > > > Hi Dave,
> > > >
> > > > > -----Original Message-----
> > > > > From: Dave Chinner [mailto:david@fromorbit.com]
> > > > > Sent: Thursday, January 21, 2016 5:31 AM
> > > > > To: linux-f2fs-devel@lists.sourceforge.net
> > > > > Subject: [f2fs-dev] [oops, 4.4-rc8] warn + oops during generic/204
> > > > >
> > > > > Hi f2fs folks,
> > > > >
> > > > > I just ran xfstests on f2fs using defaults and a pair of 4GB ram
> > > > > disks for the test and scratch devices, and it hard locked the
> > > > > machine with this failure in generic/204:
> > > >
> > > > Thanks for your report! :)
> > > >
> > > > Hi all,
> > > >
> > > > We didn't handle well with the case of inline data storm which floods
> > > > full disk. Actually the reason is: if we have 10M free space, and user
> > > > fillings the disk with ~10M inline data, then in memory there are ~10M
> > > > dirty inline datas and ~10M dirty inodes, once inodes were writebacked
> > > > before inline datas, all free space will be occupied, then we have to
> > > > write these dirty inline datas to ovp area which doesn't have enough
> > > > space there normally.
> > >
> > > Well, I think the user block count was wrong which is determined by mkfs.f2fs.
> > > When writing inline_data, gc should activate to reclaim the space, but it
> > > seems it couldn't do that cause there is no victim.
> > > So, when taking a look at mkfs, I suspect that the number of total user blocks
> > > does not consider our current segments, which is 6 by default.
> > > IOWs, we gave more blocks to users, which turns out actually gc couldn't get a
> > > victim from them in this case.
> >
> > Hmm, I don't think this could fix similar inline storm issue, I change some
> > parameters in generic/204 like below patch, and do the test with your patch
> > based on commit 9b72a388f586 ("f2fs: skip releasing nodes in chindless extent
> > tree"), oops occurs again, still the same problem. :(
> 
> Urg, yes.
> 
> >
> > ---
> >  tests/generic/204 | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/generic/204 b/tests/generic/204
> > index 24a2a94..4db1533 100755
> > --- a/tests/generic/204
> > +++ b/tests/generic/204
> > @@ -56,7 +56,7 @@ _scratch_mkfs 2> /dev/null | _filter_mkfs 2> $tmp.mkfs > /dev/null
> >  # And v4/512 v5/1k xfs don't have enough free inodes, set imaxpct=50 at mkfs
> >  # time solves this problem.
> >  [ $FSTYP = "xfs" ] && MKFS_OPTIONS="$MKFS_OPTIONS -l size=7m -i maxpct=50"
> > -SIZE=`expr 106 \* 1024 \* 1024`
> > +SIZE=`expr 406 \* 1024 \* 1024`
> >
> >  _scratch_mkfs_sized $SIZE $dbsize 2> /dev/null \
> >  		| _filter_mkfs 2> $tmp.mkfs > /dev/null
> > @@ -69,7 +69,7 @@ _scratch_mount
> >  # work out correctly. Space usages is based 22500 files and 1024 reserved blocks
> >  # on a 4k block size 256 byte inode size filesystem.
> >  resv_blks=1024
> > -space=97920000
> > +space=397920000
> >
> >  # decrease files for inode size.
> >  #	22500 * (256 + 4k) = ~97MB
> > --
> > 2.6.3
> >
> > I traced the details of this issue, we can get some hints with below datas:
> >
> > steps in this issue:
> > a) generic/204: submit 22 * 512 inline data
> > b) f2fs_write_node_pages: f2fs_balance_fs_bg->f2fs_sync_fs
> > c) f2fs_write_data_pages: write inline data page into inode page
> > d) f2fs_write_node_pages: persist inode pages
> >
> >
> > Test #1, mkfs.f2fs: not patched,  generic/204: not patched:
> > [MAIN: 45(OverProv:23 Resv:16)]
> > valid user segment = 45 - 23 = 22
> > 	inline data	dentry		node		free segment	prefree+dirty
> > a)	22		1		22		39		0
> > b)	22		0		0		18		0
> > c)	0		0		22		18		0
> > d)	0		0		4		0		19
> >
> > Test #2, mkfs.f2fs: patched,  generic/204: not patched:
> > [MAIN: 45(OverProv:23 Resv:16)]
> > valid user segment = 45 - 23 - 6 = 16
> > 	inline data	dentry		node		free segment	prefree+dirty
> > a)	16		1		16		39		0
> > b)	16		0		0		23		0
> > c)	0		0		16		23		0
> > d)	0		0		0		7		16
> >
> > Test #3, mkfs.f2fs: patched,  generic/204: patched:
> > [MAIN: 195(OverProv:44 Resv:28)]
> > valid user segment = 195 - 44 - 6 = 145
> > 	inline data	dentry		node		free segment	prefree+dirty
> > a)	145		1		145		189		0
> > b)	145		0		0		45		0
> > c)	0		0		145		45		0
> > d)	0		0		99		0		46
> >
> > Once we arrive step c), we would face the danger, because writebacking
> > of dirty node page will exhaust free segments, result in oops.
> > During step c) to step d), inode pages were COWed, prefree will increase,
> > it's a pity these prefree segments could only be reused after a checkpoint,
> > however checkpoint needs more free space for flushing dirty nodes, that
> > also will exhaust free segments, this likes a chicken and egg problem.
> >
> > Any idea to solve this?
> 
> One question is why f2fs_gc couldn't make the free space during c).
> The answer was there was no victim and no prefree segments, but the dirty node
> blocks are producing suddenly.

Yes, better to avoid entering step c).

> 
> I wrote two patches regarding to this issue.
> Could you check them too?

Please see the comments on them.

thanks,

> 
> Thanks,
> 
> >
> > Thanks,
> >
> > >
> > > I could reproduce this issue, and once I reduced the number by 6 segments,
> > > I could avoid the issue.
> > >
> > > Here the change of f2fs-tools.
> > >
> > > From 411166a44009bb138eca937376863e9ce673278a Mon Sep 17 00:00:00 2001
> > > From: Jaegeuk Kim <jaegeuk@kernel.org>
> > > Date: Thu, 21 Jan 2016 05:16:37 -0800
> > > Subject: [PATCH] mkfs.f2fs: adjust current segments for total usable blocks
> > >
> > > When calculating total number of user blocks, we should reserve the current
> > > segments.
> > >
> > > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > > ---
> > >  mkfs/f2fs_format.c | 7 ++++++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
> > > index 2c81ecc..b25a490 100644
> > > --- a/mkfs/f2fs_format.c
> > > +++ b/mkfs/f2fs_format.c
> > > @@ -474,7 +474,12 @@ static int f2fs_write_check_point_pack(void)
> > >
> > >  	/* main segments - reserved segments - (node + data segments) */
> > >  	set_cp(free_segment_count, get_sb(segment_count_main) - 6);
> > > -	set_cp(user_block_count, ((get_cp(free_segment_count) + 6 -
> > > +	if (get_cp(free_segment_count) <= get_cp(overprov_segment_count)) {
> > > +		MSG(0, "Error: Too small size\n");
> > > +		goto free_sum_compact;
> > > +	}
> > > +
> > > +	set_cp(user_block_count, ((get_cp(free_segment_count) -
> > >  			get_cp(overprov_segment_count)) * config.blks_per_seg));
> > >  	/* cp page (2), data summaries (1), node summaries (3) */
> > >  	set_cp(cp_pack_total_block_count, 6 + get_sb(cp_payload));
> > > --
> > > 2.6.3
> >


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140