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 8E314C433EF for ; Mon, 22 Nov 2021 22:08:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232955AbhKVWLU (ORCPT ); Mon, 22 Nov 2021 17:11:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231256AbhKVWLU (ORCPT ); Mon, 22 Nov 2021 17:11:20 -0500 Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45C9BC061574 for ; Mon, 22 Nov 2021 14:08:13 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id l8so18018746qtk.6 for ; Mon, 22 Nov 2021 14:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20210112.gappssmtp.com; s=20210112; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=F9rZNuDq+dHvDicprv1NyKqx8G2mf6YGPZRjLyH0Qxc=; b=6qJ3oPs9Sx1kvHfWsatFq8AwtN//7B8bux6dEWvP91VlnyZrTzhTiSP9FaufGEhbAZ nNlRl0pKfshbHhQ9o7RZv3FZcQBCwCtnIINofviP9wXIWRHdh0yKMWWNhTa1OXp0JXYK 8wdmYbLRbCujRU8gFWfpnVqGt6LxWliBdnF/OruBa1YquCj6PUDMlwkqsSPdj9XjUiAl EJiGMDO0zldg1j8opU04TyLqv46+70dqNXt1AiP61V95kZp4d+w5WAl+4y2WgfrJIChd MBh/fGJE3tedKNCzNBxu2EyXwCI0t31SSxj9vXks1Ly3uiYo4AHqj4jQRLqX1nimOxt4 U4Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=F9rZNuDq+dHvDicprv1NyKqx8G2mf6YGPZRjLyH0Qxc=; b=ijNv4jDRy1GJ0LJK3kxnXarfipxkjs0a/YOREihIJV/62atQ9tfe/ex/xds3tnqHov yFFjzyB6KTRaAZBDJ+oPqzWVVevbuzDPKUjuOPkSGJy54wnQ8DzyTEHuvenRqisWOtKz 3Xq+RvbeqtBM+noG0T+dxv85C6pS4JKrJNpchForp0tsk5H94OSuLGZ3x3Q01jdej5N/ ww9cKBLnjYhlBtXeSCuK2Uo43GVFcBJ0/qeYhxPT6MTyD9uNZXAJctZX6t7lZ6fuGDdG +14ujRu8BcDq4FbbRW3hlRYwlnVdGqHwU6Q3VqgLNttR1AGeIM3KG8Zuj5BK1GonQnuv biYg== X-Gm-Message-State: AOAM530IFv1cg+mGGJSP/ieZqNIuyrMu/kMF69AZy0e4Xw+LA3GAWq3t FwCcLS69zUSOrQ2bQccDmHtkRQ== X-Google-Smtp-Source: ABdhPJy31P0VpL0uuo/4ZrvlP1yLFKWQxexZsI4LpaiKf1qdOT8OffWxIM+pN3LJiM4ecIpdI6iINg== X-Received: by 2002:a05:622a:148e:: with SMTP id t14mr671812qtx.266.1637618892316; Mon, 22 Nov 2021 14:08:12 -0800 (PST) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id g5sm5176239qko.12.2021.11.22.14.08.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Nov 2021 14:08:11 -0800 (PST) From: Josef Bacik To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org, kernel-team@fb.com Subject: [PATCH] fstests: generic/260: don't fail for certain fstrim ops on btrfs Date: Mon, 22 Nov 2021 17:08:10 -0500 Message-Id: <175b1ef92bbd2a48e2efb80d0064ca91aab1402e.1637618880.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.26.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org We have always failed generic/260, because it tests to see if the file system will reject a trim range that is above the reported fs size. However for btrfs we will happily remap logical byte offsets within the file system, so you can end up with bye offsets past the end of the reported end of the file system. Thus we do not fail these weird ranges. We also don't have the concept of allocation groups, so the other test that tries to catch overflow doesn't apply to us either. Fix this by simply using an offset that will fail (once a related kernel path is applied) for btrfs. This will allow us to test the different overflow cases that do apply to btrfs, and not muddy up test results by giving us a false negative for the cases that do not apply to btrfs. Signed-off-by: Josef Bacik --- tests/generic/260 | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tests/generic/260 b/tests/generic/260 index b15b4e57..b4d72e0f 100755 --- a/tests/generic/260 +++ b/tests/generic/260 @@ -31,6 +31,7 @@ fssize=$($DF_PROG -k | grep "$SCRATCH_MNT" | grep "$SCRATCH_DEV" | awk '{print beyond_eofs=$(_math "$fssize*2048") max_64bit=$(_math "2^64 - 1") +[ $FSTYP == "btrfs" ] && beyond_eofs=$max_64bit # All these tests should return EINVAL # since the start is beyond the end of @@ -128,6 +129,12 @@ case $FSTYP in len=$start export MKFS_OPTIONS="-f -d agsize=$(_math "$agsize*$bsize") -b size=$bsize" ;; + btrfs) + # Btrfs doesn't care about any of this, just test max_64bit + # since it'll fail + start=$max_64bit + len=$(_math "$start / 2") + ;; *) # (2^32-1) * 4096 * 65536 == 32bit max size * block size * ag size start=$(_math "(2^32 - 1) * 4096 * 65536") -- 2.26.3