From: Chao Yu <yuchao0@huawei.com>
To: "Ondřej Jirman" <megi@xff.cz>, "Jaegeuk Kim" <jaegeuk@kernel.org>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] Writes stoped working on f2fs after the compression support was added
Date: Wed, 11 Mar 2020 18:51:23 +0800 [thread overview]
Message-ID: <c3d53657-7c2a-9d2f-9111-048db6e30a7e@huawei.com> (raw)
In-Reply-To: <20200311103309.m52hdut7mt7crt7g@core.my.home>
Hi,
On 2020/3/11 18:33, Ondřej Jirman wrote:
> Hello,
>
> On Wed, Mar 11, 2020 at 05:02:10PM +0800, Chao Yu wrote:
>> Hi,
>>
>> Sorry for the delay.
>>
>> On 2020/3/6 20:02, Ondřej Jirman wrote:
>>> Hello,
>>>
>>> On Thu, Feb 27, 2020 at 10:01:50AM +0800, Chao Yu wrote:
>>>> On 2020/2/27 2:05, Ondřej Jirman wrote:
>>>>>
>>>>> No issue after 7h uptime either. So I guess this patch solved it for some
>>>>> reason.
>>>>
>>>> I hope so as well, I will send a formal patch for this.
>>>
>>> So I had it happen again, even with the patches. This time in f2fs_rename2:
>>
>> Oops, it looks previous fix patch just cover the root cause... :(
>>
>> Did this issue still happen frequently? If it is, would you please apply patch
>> that prints log during down/up semaphore.
>
> Not frequently. Just once. I couldn't afford FS corruption during update,
Alright.
> so I reverted the compression support shortly after.
What I can see is that filesystem was just stuck, rather than image became
corrupted, I guess the condition is not such bad, anyway, it's okay to just
revert compression support for now to keep fs stable.
>
> But I wasn't stressing the system much with FS activity after applying the
> initial fix.
>
>> And once we revert compression support patch, this issue will disappear, right?
>
> Yes, AFAIK. I reverted it and run a few cycles of install 500MiB worth of
> packages, uninstall the packages with pacman. And it didn't re-occur. I never
> saw any issues with compression support patch reverted.
Okay, compression support may increase stack usage during page writeback, it
shouldn't overflow the stack, otherwise it could cause panic in somewhere else,
but still can find any clue why this is related to compression support patch...
>
>> Btw, did you try other hardware which is not Arm v7?
>
> Yes, but I didn't ever see it on anything else. Just on two 8 core cortexes A7.
> (2 clusters)
Not sure, maybe this issue is related to arm v7 architecture.
Thanks,
>
> regards,
> o.
> .
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2020-03-11 10:51 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 22:23 [f2fs-dev] [PATCH 1/6] f2fs: call f2fs_balance_fs outside of locked page Jaegeuk Kim
2019-12-09 22:23 ` [f2fs-dev] [PATCH 2/6] f2fs: declare nested quota_sem and remove unnecessary sems Jaegeuk Kim
2019-12-10 6:20 ` Chao Yu
2019-12-09 22:23 ` [f2fs-dev] [PATCH 3/6] f2fs: keep quota data on write_begin failure Jaegeuk Kim
2019-12-10 6:22 ` Chao Yu
2019-12-09 22:23 ` [f2fs-dev] [PATCH 4/6] f2fs: should avoid recursive filesystem ops Jaegeuk Kim
2019-12-10 6:22 ` Chao Yu
2019-12-09 22:23 ` [f2fs-dev] [PATCH 5/6] f2fs: set GFP_NOFS when moving inline dentries Jaegeuk Kim
2019-12-10 6:22 ` Chao Yu
2019-12-09 22:23 ` [f2fs-dev] [PATCH 6/6] f2fs: set I_LINKABLE early to avoid wrong access by vfs Jaegeuk Kim
2019-12-10 6:37 ` Chao Yu
2019-12-11 1:21 ` Jaegeuk Kim
2019-12-11 1:23 ` Chao Yu
2019-12-11 1:31 ` Jaegeuk Kim
2019-12-11 1:42 ` Chao Yu
2019-12-12 16:55 ` Jaegeuk Kim
2019-12-10 2:09 ` [f2fs-dev] [PATCH 1/6] f2fs: call f2fs_balance_fs outside of locked page Chao Yu
2020-02-22 4:46 ` Ondřej Jirman
2020-02-22 18:17 ` [f2fs-dev] Writes stoped working on f2fs after the compression support was added Ondřej Jirman
2020-02-24 10:37 ` Chao Yu
2020-02-24 10:41 ` Chao Yu
2020-02-24 13:58 ` Ondřej Jirman
2020-02-24 14:03 ` Ondřej Jirman
2020-02-24 14:31 ` Ondřej Jirman
2020-02-25 11:24 ` Chao Yu
2020-02-25 11:32 ` Chao Yu
2020-02-25 12:08 ` Ondřej Jirman
2020-02-25 12:27 ` Ondřej Jirman
2020-02-26 1:58 ` Chao Yu
2020-02-26 12:11 ` Ondřej Jirman
2020-02-26 18:05 ` Ondřej Jirman
2020-02-27 2:01 ` Chao Yu
2020-03-06 12:02 ` Ondřej Jirman
2020-03-06 12:43 ` Ondřej Jirman
2020-03-11 9:02 ` Chao Yu
2020-03-11 10:33 ` Ondřej Jirman
2020-03-11 10:51 ` Chao Yu [this message]
2020-03-11 11:01 ` Ondřej Jirman
2020-03-11 12:13 ` Chao Yu
2020-03-11 17:01 ` Jaegeuk Kim
2020-03-22 10:15 ` Chao Yu
2020-02-24 14:20 ` Ondřej Jirman
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=c3d53657-7c2a-9d2f-9111-048db6e30a7e@huawei.com \
--to=yuchao0@huawei.com \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=megi@xff.cz \
/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;
as well as URLs for NNTP newsgroup(s).