From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Chao Yu <chao2.yu@samsung.com>
Cc: 'Dave Chinner' <david@fromorbit.com>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [oops, 4.4-rc8] warn + oops during generic/204
Date: Fri, 22 Jan 2016 09:52:59 +0800 [thread overview]
Message-ID: <20160122015259.GB53329@jaegeuk> (raw)
In-Reply-To: <008501d15441$68c7d870$3a578950$@samsung.com>
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
next prev parent reply other threads:[~2016-01-22 1:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 21:31 [oops, 4.4-rc8] warn + oops during generic/204 Dave Chinner
2016-01-21 11:46 ` Chao Yu
2016-01-22 1:52 ` Jaegeuk Kim [this message]
2016-01-22 6:15 ` Chao Yu
2016-01-23 20:15 ` Jaegeuk Kim
2016-01-25 9:39 ` Chao Yu
2016-01-22 9:27 ` Chao Yu
2016-01-22 1:42 ` Jaegeuk Kim
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=20160122015259.GB53329@jaegeuk \
--to=jaegeuk@kernel.org \
--cc=chao2.yu@samsung.com \
--cc=david@fromorbit.com \
--cc=linux-f2fs-devel@lists.sourceforge.net \
/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