Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp474090pxb; Wed, 24 Feb 2021 07:06:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJxZQcDSyFgO7Emq94iZWugK1dXVcKgHdCFPhC/tVwhrso4Y39pziErsGrjWhDXNCB7V7/Ap X-Received: by 2002:a50:8a90:: with SMTP id j16mr32867560edj.334.1614179209976; Wed, 24 Feb 2021 07:06:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614179209; cv=none; d=google.com; s=arc-20160816; b=ECVrRnU0mltL3nB9IKgCer7bjD8C8jTHJ3dGHuGdnHki1sDSEksLluW2pxqEUhmpn3 jC/DtRYJPMB8xZjOcA6CYBZPwQwZvTZ+6CRbuFxgeBOdROPMdfl+cNjHpfjgRfpzq9z2 ZxV+tJOA7HF2/7IUUL0TMZE1SgrnlgEsIAvB1UGBR2q3X1Wk4Drzh2s2zJBGkSvwlbtD tId0BBVfAad1ZxYDHTifN4WXWH1m9KqM353gtz7sahN20yZzUkz4zCmoQ6Yp1jtKzv8W 9ypRmLLc5IhP4BMd6Vn0tMet1esWota6t8jrXIY5W7CTkPT4beIofFiGIlXjIDLXMcSX SD3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=5QPd8F17MeMUkB+NAFIqOMHhQEtQfQDk+gHUU+LiAbE=; b=Zqmnw5FD9QyJixqn4NWDKDB1DSeesIbyVZsyXm4VgjRWbCXH7zZ18AajzUoU8/7X+p qIk5+nsEY2uxGfnn04I3Tmis1vPY0OanqaKPAddPRKGSinyoHEhn7Z/ApHXNuCcp525e BtP48Zm/uvI3soCUo+AzIoGvzwrsYwCNUi+hu7EAGdnuhS+EnIe/I5ZDaXzrqLraJ2QP wB/6sYBTpiETlDyy7fXemG5u50kvh8kIxdcASzOKDKizCePdRbq4gGjQYUALH3kNMXkt Wgf58KHqGHM1ZJnj0JA6aqY1WDLlYJ3MlwRoCbF0qNvaS/Ohpxb0Rph+rMl6yzR58zT8 GmoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk7si1446657ejb.570.2021.02.24.07.06.11; Wed, 24 Feb 2021 07:06:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232588AbhBXPAu (ORCPT + 99 others); Wed, 24 Feb 2021 10:00:50 -0500 Received: from out30-133.freemail.mail.aliyun.com ([115.124.30.133]:43540 "EHLO out30-133.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237001AbhBXNcn (ORCPT ); Wed, 24 Feb 2021 08:32:43 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=eguan@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0UPT6LS4_1614173506; Received: from localhost(mailfrom:eguan@linux.alibaba.com fp:SMTPD_---0UPT6LS4_1614173506) by smtp.aliyun-inc.com(127.0.0.1); Wed, 24 Feb 2021 21:31:46 +0800 Date: Wed, 24 Feb 2021 21:31:46 +0800 From: Eryu Guan To: Chengguang Xu Cc: Su Yue , guaneryu , fstests , linux-btrfs , linux-fsdevel , linux-ext4 , linux-xfs Subject: Re: [PATCH] generic/473: fix expectation properly in out file Message-ID: <20210224133146.GE96449@e18g06458.et15sqa> References: <20210223134042.2212341-1-cgxu519@mykernel.net> <4ki1rjgu.fsf@damenly.su> <177d33c0982.10b8858b515683.1169986601273192029@mykernel.net> <177d3666a3c.e47042d016248.8805085013477614929@mykernel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <177d3666a3c.e47042d016248.8805085013477614929@mykernel.net> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Feb 24, 2021 at 05:37:20PM +0800, Chengguang Xu wrote: > ---- 在 星期三, 2021-02-24 17:22:35 Su Yue 撰写 ---- > > > > On Wed 24 Feb 2021 at 16:51, Chengguang Xu > > wrote: > > > > > ---- 在 星期三, 2021-02-24 15:52:17 Su Yue 撰写 > > > ---- > > > > > > > > Cc to the author and linux-xfs, since it's xfsprogs related. > > > > > > > > On Tue 23 Feb 2021 at 21:40, Chengguang Xu > > > > > > > > wrote: > > > > > > > > > It seems the expected result of testcase of "Hole + Data" > > > > > in generic/473 is not correct, so just fix it properly. > > > > > > > > > > > > > But it's not proper... > > > > > > > > > Signed-off-by: Chengguang Xu > > > > > --- > > > > > tests/generic/473.out | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/tests/generic/473.out b/tests/generic/473.out > > > > > index 75816388..f1ee5805 100644 > > > > > --- a/tests/generic/473.out > > > > > +++ b/tests/generic/473.out > > > > > @@ -6,7 +6,7 @@ Data + Hole > > > > > 1: [256..287]: hole > > > > > Hole + Data > > > > > 0: [0..127]: hole > > > > > -1: [128..255]: data > > > > > +1: [128..135]: data > > > > > > > > > The line is produced by `$XFS_IO_PROG -c "fiemap -v 0 65k" > > > > $file | > > > > _filter_fiemap`. > > > > 0-64k is a hole and 64k-128k is a data extent. > > > > fiemap ioctl always returns *complete* ranges of extents. > > > > > > Manual testing result in latest kernel like below. > > > > > > [root@centos test]# uname -a > > > Linux centos 5.11.0+ #5 SMP Tue Feb 23 21:02:27 CST 2021 x86_64 > > > x86_64 x86_64 GNU/Linux > > > > > > [root@centos test]# xfs_io -V > > > xfs_io version 5.0.0 > > > > > > [root@centos test]# stat a > > > File: a > > > Size: 4194304 Blocks: 0 IO Block: 4096 > > > regular file > > > Device: fc01h/64513d Inode: 140 Links: 1 > > > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ > > > root) > > > Access: 2021-02-24 16:33:20.235654140 +0800 > > > Modify: 2021-02-24 16:33:25.070641521 +0800 > > > Change: 2021-02-24 16:33:25.070641521 +0800 > > > Birth: - > > > > > > [root@centos test]# xfs_io -c "pwrite 64k 64k" a > > > wrote 65536/65536 bytes at offset 65536 > > > 64 KiB, 16 ops; 0.0000 sec (992.063 MiB/sec and 253968.2540 > > > ops/sec) > > > > > > [root@VM-8-4-centos test]# xfs_io -c "fiemap -v 0 65k" a > > > a: > > > EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS > > > 0: [0..127]: hole 128 > > > 1: [128..135]: 360..367 8 0x1 > > > > > > > Sorry, my carelessness. I only checked btrfs implementation but > > xfs > > and ext4 do return the change you made. > > > > Yeah, it seems there is no bad side effect to show only specified range of extents > and keep all the same behavior is also good for testing. I can post a fix patch for > this but before that let us to wait some feedback from maintainers and experts. generic/473 is marked as broken by commit 715eac1a9e66 ("generic/47[23]: remove from auto/quick groups"). Thanks, Eryu