From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1744C433FE for ; Sat, 5 Nov 2022 23:30:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229949AbiKEXaq (ORCPT ); Sat, 5 Nov 2022 19:30:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230119AbiKEXad (ORCPT ); Sat, 5 Nov 2022 19:30:33 -0400 Received: from out20-183.mail.aliyun.com (out20-183.mail.aliyun.com [115.124.20.183]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9408A10B67 for ; Sat, 5 Nov 2022 16:30:31 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE;BC=0.05895857|-1;BR=01201311R951S22rulernew998_84748_2000303;CH=blue;DM=|CONTINUE|false|;DS=CONTINUE|ham_system_inform|0.0178569-0.0122455-0.969898;FP=0|0|0|0|0|-1|-1|-1;HT=ay29a033018047212;MF=wangyugui@e16-tech.com;NM=1;PH=DS;RN=1;RT=1;SR=0;TI=SMTPD_---.Q0JXbsv_1667691028; Received: from 192.168.2.112(mailfrom:wangyugui@e16-tech.com fp:SMTPD_---.Q0JXbsv_1667691028) by smtp.aliyun-inc.com; Sun, 06 Nov 2022 07:30:29 +0800 Date: Sun, 06 Nov 2022 07:30:29 +0800 From: Wang Yugui To: linux-btrfs@vger.kernel.org Subject: newer /bin/cp have worse btrfs fiemap performance. Message-Id: <20221106073028.71F9.409509F4@e16-tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.75.04 [en] Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Hi, newer /bin/cp have worse btrfs fiemap performance. btrfs version: misc-next 750de989d367(the lastest of 2022/11/05) /bin/cp versions(run them on the same server) 8.22 copy from centos/7.9 8.30 rocklinux/9.0 9.1 local build, https://kojipkgs.fedoraproject.org/packages/coreutils/9.1/8.eln121/ test case: /bin/cp /mnt/test/file1 /dev/null /mnt/test/file1 is created by https://lore.kernel.org/linux-btrfs/YuwUw2JLKtIa9X+S@localhost.localdomain/T/#T and /mnt/test/file1 is 256M. file is not cached: 'echo 3 >/proc/sys/vm/drop_caches' file is cached: run '/bin/cp /mnt/test/file1 /dev/null' again. performance result(/bin/cp /mnt/test/file1 /dev/null): /bin/cp 9.1 file is not cached: 94.85(1:34.85) file is cached: 1982.43(33:02.43) /bin/cp 8.30 file is not cached: 1.48(0:01.48) file is cached:14.07(0:14.07) /bin/cp 8.22 file is not cached: 0.53(0:00.53) file is cached: 0.10(0:00.10) as a compare, we test it on xfs too. 1) /bin/cp 8.22/8.30/9.1 have almost same performance. 2) the case(the file is cached) is faster than the case(the file is not cached). strace show that the logical of /bin/cp 8.30 and 9.1 are different. /bin/cp 8.30 lseek(3, 198737920, SEEK_SET) = 198737920 write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(3, "a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 write(4, "a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 lseek(3, 198746112, SEEK_SET) = 198746112 write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(3, "a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 write(4, "a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 /bin/cp 9.1 lseek(3, 880640, SEEK_DATA) = 884736 lseek(3, 884736, SEEK_HOLE) = 888832 lseek(3, 884736, SEEK_SET) = 884736 write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(3, "a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 write(4, "a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 lseek(3, 888832, SEEK_DATA) = 892928 lseek(3, 892928, SEEK_HOLE) = 897024 lseek(3, 892928, SEEK_SET) = 892928 write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(3, "a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 write(4, "a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 Do we need some job in btrfs to support /bin/cp 9.1 well, or /bin/cp 9.1 is just wrong? Best Regards Wang Yugui (wangyugui@e16-tech.com) 2022/11/06