From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034854AbcIZBEd (ORCPT ); Sun, 25 Sep 2016 21:04:33 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:33856 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034538AbcIZBEc (ORCPT ); Sun, 25 Sep 2016 21:04:32 -0400 Subject: Re: [PATCH 2/3] f2fs: support checkpoint error injection To: Jaegeuk Kim References: <20160923052458.83849-1-yuchao0@huawei.com> <20160923052458.83849-2-yuchao0@huawei.com> <20160923235345.GA23989@jaegeuk> <3cf62ebc-3bfa-b64c-5e63-cb3170560ac0@huawei.com> <20160924005216.GA24515@jaegeuk> <53ec17da-e6b3-cab4-d107-20ead1381ebd@huawei.com> <20160924181034.GB25123@jaegeuk> CC: , , From: Chao Yu Message-ID: <1b93a869-a57f-4ab7-07a3-8f37666ce066@huawei.com> Date: Mon, 26 Sep 2016 09:03:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160924181034.GB25123@jaegeuk> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57E87406.00E1,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3408d4b896b305b3db5c4d92c5148f53 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/9/25 2:10, Jaegeuk Kim wrote: > On Sat, Sep 24, 2016 at 11:32:08AM +0800, Chao Yu wrote: >> On 2016/9/24 8:52, Jaegeuk Kim wrote: >>> On Sat, Sep 24, 2016 at 08:46:54AM +0800, Chao Yu wrote: >>>> Hi Jaegeuk, >>>> >>>> On 2016/9/24 7:53, Jaegeuk Kim wrote: >>>>> Hi Chao, >>>>> >>>>> The basic rule is to stop every operations once CP_ERROR_FLAG is set. >>>>> But, this patch simply breaks the rule. >>>>> For example, f2fs_write_data_page() currently exits with mapping_set_error(). >>>>> So this patch incurs missing dentry blocks in a valid checkpoint. >>>> >>>> Yes, that's right. >>>> >>>> How about triggering checkpoint error in f2fs_stop_checkpoint? >>> >>> Let's just use src/godown in xfstests, since we don't need to trigger this >>> multiple times in runtime. >> >> After we inject checkpoint error into f2fs at first time, all write IOs will be >> refused to be writebacked to storage, meanwhile read IOs can continuously go >> through f2fs, so with checkpoint error injection being supported, we can support >> to trigger random analogously power off by f2fs itself, instead of using tools. >> It means it doesn't needs specified test cases where we must use godown ioctl, >> but with normal testcases in xfstest/fsstress/lkp, in CP error injection enabled >> f2fs, we can test power off cases. > > But, in this approach, the test coverage would be quite limited. > In my testcase, I'm randomly injecting godown while fsstress is running, which > mimics really random power failures, as I believe. I'm running this infinitely > with fscking at every run. > > Anyway, in order to do this without godown, how about background_gc thread to > trigger f2fs_stop_checkpoint? Yeap, better. What do you think of adding random f2fs_stop_checkpoint in f2fs_balance_fs? power off can be triggered if gc thread is not running. Thanks, > >> >> Thanks, > > . >