From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eryu Guan Subject: Re: [PATCH v2] generic: test i_mode recovery after power failure Date: Sat, 9 Mar 2019 18:15:10 +0800 Message-ID: <20190309101510.GO2824@desktop> References: <20190305114744.129633-1-yuchao0@huawei.com> <20190305205344.GC26298@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1h2Z0m-0005lY-Ig for linux-f2fs-devel@lists.sourceforge.net; Sat, 09 Mar 2019 10:15:24 +0000 Received: from mail-pf1-f194.google.com ([209.85.210.194]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) id 1h2Z0l-00Ep0s-0m for linux-f2fs-devel@lists.sourceforge.net; Sat, 09 Mar 2019 10:15:24 +0000 Received: by mail-pf1-f194.google.com with SMTP id i20so16020457pfo.6 for ; Sat, 09 Mar 2019 02:15:22 -0800 (PST) Content-Disposition: inline In-Reply-To: <20190305205344.GC26298@dastard> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net To: Dave Chinner Cc: fdmanana@gmail.com, fstests@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net On Wed, Mar 06, 2019 at 07:53:44AM +1100, Dave Chinner wrote: > On Tue, Mar 05, 2019 at 07:47:44PM +0800, Chao Yu wrote: > > After fsync, filesystem should guarantee inode metadata including > > permission info being persisted, so even after sudden power-cut, > > during mount, we should recover i_mode fields correctly, in order > > to not loss those meta info. > > > > So adding this testcase to check whether generic filesystem can > > guarantee that. > > Can I make a suggestion here? > > I've noticed that we are getting a lot of these one-off, random > "fsync persists one specific piece of metadata in one specific case" > tests, mainly in response to some fsync bug that was found in btrfs. > This is reactive, and does not find new bugs in this area. > > We are also beyond the point where the number of tests is > maintainable (e.g. to be able to make infrastructure changes), so we > really should be looking to consolidate largely similar tests into > single tests where possible. This sounds reasonable, and could reduce the test time a bit as well. > > I'd strongly suggest that a robust fsync tester should be written > for all the cases that are currently being addressed in an ad hoc > fashion. Then they can be consolidated into a single test run, and > we can get rid of all the one-off "fsync failed on this thing>" tests from the harness. > > Oh, wait, we *already have that infrastructure*: src/fsync-tester.c > and generic/311. > > Can we please consider rolling all of these "do something, fsync, > drop-writes, remount check" into fsync-tester.c and do the same for > all future one-off "did fsync persist X" tests? I'd like to take this patch and the one from Filipe for now, and look into folding them into fsync-tester later, in a separate patch. Thanks, Eryu