From patchwork Tue Jul 11 11:13:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Foster X-Patchwork-Id: 9834503 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1DFE860325 for ; Tue, 11 Jul 2017 11:13:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0D07F28479 for ; Tue, 11 Jul 2017 11:13:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F21502844E; Tue, 11 Jul 2017 11:13:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 720E82843B for ; Tue, 11 Jul 2017 11:13:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755451AbdGKLNu (ORCPT ); Tue, 11 Jul 2017 07:13:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46430 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753283AbdGKLNn (ORCPT ); Tue, 11 Jul 2017 07:13:43 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 876F183F45 for ; Tue, 11 Jul 2017 11:13:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 876F183F45 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bfoster@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 876F183F45 Received: from bfoster.bfoster (dhcp-41-20.bos.redhat.com [10.18.41.20]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6AFA15D964 for ; Tue, 11 Jul 2017 11:13:42 +0000 (UTC) Received: by bfoster.bfoster (Postfix, from userid 1000) id 6D6541205DE; Tue, 11 Jul 2017 07:13:41 -0400 (EDT) Date: Tue, 11 Jul 2017 07:13:41 -0400 From: Brian Foster To: fstests@vger.kernel.org Subject: Re: [WIP PATCH V2] Buffer resubmittion test Message-ID: <20170711111341.GA24477@bfoster.bfoster> References: <20170710133418.7083-1-cmaiolino@redhat.com> <20170710145522.GA17652@bfoster.bfoster> <20170710150612.ofjodvipik7wvpnu@eorzea.usersys.redhat.com> <20170710151343.GB17652@bfoster.bfoster> <20170710155223.xmco3qgecbffug56@eorzea.usersys.redhat.com> <20170711083955.zw6ksal76mh2fozl@eorzea.usersys.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170711083955.zw6ksal76mh2fozl@eorzea.usersys.redhat.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 11 Jul 2017 11:13:42 +0000 (UTC) Sender: fstests-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Jul 11, 2017 at 10:39:55AM +0200, Carlos Maiolino wrote: > Hi Brian, > > > > > > > > > > > The test is still under xfs (rather than generic). > > > > > > > I'm still not really convinced this test should be added to generic, this tests > a very specific behavior of XFS journal, the journal behavior on XFS and ext4 > for example, are very different, > Sure, but this generally isn't how we determine whether a test is generic or fs-specific. IME, a test is made specific iff it depends on some fs-specific feature/option to run, regardless of whether the underlying problem is generic or not. Granted, if there is a major behavior discrepency between filesystems such that making this test generic would complicate the test or require a different implementation, I think that is reasonable enough for an exception. > either ext4 or btrfs for example, will remount the filesystem as RO during the > xfs_io process to fill the filesystem, so, even though the filesystem can keep > consistency, the test shows it as a failure. > > What do you think? I honestly believe it would be better to keep this test as a > XFS test, the behavior here is XFS specific. > Ok, so to me the question here is: can we make this test function normally on both XFS and other fs' that exhibit the behavior above without major changes and disrupting the original intent? For example, can the test be updated to accommodate the fact that some filesystems may go inactive after the overprovisioned write? It seems to me that it can with something as simple as the appended diff. Of course, this probably should be enhanced further to verify that the fs went read-only or to simply not ignore a freeze failure if [ $FSTYP == xfs ], etc. Brian --- 8< --- --- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/tests/xfs/999 b/tests/xfs/999 old mode 100644 new mode 100755 index b46f1cc8..5ee7521b --- a/tests/xfs/999 +++ b/tests/xfs/999 @@ -55,7 +55,6 @@ _cleanup() # real QA test starts here # Modify as appropriate. -_supported_fs xfs _supported_os Linux _require_scratch_nocheck _require_dm_target thin-pool @@ -102,7 +101,8 @@ xfs_io -f -d -c 'pwrite -b 1m 0 120m' $SCRATCH_MNT/f1 >>$seqres.full 2>&1 # This freeze will never complete until the dm-thin POOL device is extended. # This is expected, it is only used so xfsaild is triggered to flush AIL items. -fsfreeze -f $SCRATCH_MNT & +fsfreeze -f $SCRATCH_MNT >>$seqres.full 2>&1 & +freezepid=$! # Wait enough so xfsaild can run sleep 10 @@ -110,9 +110,12 @@ sleep 10 # Make some extra space available so the freeze above can proceed lvextend -L $newpsize $vgname/$poolname >>$seqres.full 2>&1 +wait -n $freezepid +ret=$? + # Try to thaw the filesystem, and complete test if if succeed. # NOTE: This will hang on affected XFS filesystems. -fsfreeze -u $SCRATCH_MNT +[ $ret == 0 ] && fsfreeze -u $SCRATCH_MNT echo "Test OK" status=0