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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 449B8E65D34 for ; Fri, 22 Nov 2024 08:49:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A37056B00C1; Fri, 22 Nov 2024 03:49:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C00E6B00C2; Fri, 22 Nov 2024 03:49:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 839BB6B00C3; Fri, 22 Nov 2024 03:49:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 62CF16B00C1 for ; Fri, 22 Nov 2024 03:49:38 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0CD204101A for ; Fri, 22 Nov 2024 08:49:38 +0000 (UTC) X-FDA: 82813104864.07.E9B2271 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf06.hostedemail.com (Postfix) with ESMTP id 058F0180003 for ; Fri, 22 Nov 2024 08:48:57 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=I10nxVfA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of amir73il@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=amir73il@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732265239; a=rsa-sha256; cv=none; b=LU5SIIxvrZzCvaCeym8nK4T2TGw6CfN1+hg64pvYvYUSDuyhFFBUla1COocW1Ud8aDXexu wRt46keCMuklZJck3nPUJxM9ihrtCY5u6yJiHqPxglaw21ruq8yIV2g3IsLfkKBQG50mS/ oSX0++xSQYMf9kn3gd5LU55tAI9EgFc= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=I10nxVfA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of amir73il@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=amir73il@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732265239; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0kO/z/IdbIn2zdD3nJFBvE5a6HQLfpizTI0u8jsOVaE=; b=3YsUSwCenEWCvpoZfr4BqAmze6kOpiBw1ITI2RZ3OuDDBkxeMXBwMzOTsgw0L0jiEfg2fZ 3vnqKvsgwQa/wTDIl/sg2n7SYlMaCjOkEh+Zv7x5e11/Q83Y+cQAtbGNAk9TuzonNBlH6j GjRJKuwvTr4loMCbAinnxLBPf6TSdBo= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-aa4d257eb68so351234466b.0 for ; Fri, 22 Nov 2024 00:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732265374; x=1732870174; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0kO/z/IdbIn2zdD3nJFBvE5a6HQLfpizTI0u8jsOVaE=; b=I10nxVfAG7V8DEHumClOjcYEtJs5MTCY0PmHVMpGSoe/FjPGCi70eJo9y2KIhpUyrX eN5fw9rXI2ChP/8dasrdghrIOwBL396ToBM7dDnJtTsKUWOQtJEZZhoTxuvh29gv6GnU axLPdNOlxRgqg37HV8b3aaDE7TGVmUOiUCSAnM0scSMZSBxQmzkQRozUNgBXASRypKt8 cOlo678Nsd8YNj7ELthdRrUUcv9NFCgvfbuUWi6xTcuqix8gChQP36u+5qXe9zoaUAJg xt8PlRMDIUjVc4dT94+71DzlMPTmcN1U4St3pYliVhQKcgDK2ElohFuheZQyQCoYWJqz +QKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732265374; x=1732870174; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0kO/z/IdbIn2zdD3nJFBvE5a6HQLfpizTI0u8jsOVaE=; b=Cj/DnLk7DEkqRPY+yp39S/SWzLpSF68i9YOWvIp0s9nuIFpbeQ6fhcosV150X8imsd UIV6Q3QZFyAj+3v3c4jlRmdCzAiiE4lUSVKQLNASbsL2xsM81rHe8H3Sa1/8eMSfuG+3 2ZNbb7qUO2gWycTp81J38qSpu+buldBif1OaWdQG0M+nFPD/zSMIEIVQQmPjiop8Nx8f 0DRrjN6YyJ5bqNqHASQhH4HiBg/vr3ZizEjlyZSpliaMFzga40cc6kycr/ZqA/NahiYv G0ZeAPL+jE/OVOwuH0oS6kVNwBA7tfkp1/3Ww+q3a25WysFrXFBx34HWrBDNSkLTlJsX Gj7w== X-Forwarded-Encrypted: i=1; AJvYcCUJ2KqKeOGwzfS24gdHWM38iPA7hN6PHj9BNnDCSkPA43HAu0Zf6qC7nZRUZ0G2dPgGA1Su/2rPBQ==@kvack.org X-Gm-Message-State: AOJu0YzVSDpNQ5XzFPX0fBgUVZkSxf24w/46J2zIzsu6MRpKGeCm3Lr/ 8u0XdrE5cUxw8CBe5UciRDbwQ45Oz7Zkp+/NPD2Y+CvmhP347rqTpRg/Z0HteJnjgDMZBJtxymi 9sX9UjT6+ToLOBET6c+q+nu4NUTQ= X-Gm-Gg: ASbGncuGFjITqlqIkTFo/L2nlN3IgLiq8Q+B5Bo2RM+9RF4iN0Pnl/k2SeA+aZcWEFi hw6k6q0Y9kvmV/F1RKx3hC/79VgUcnGg= X-Google-Smtp-Source: AGHT+IF6mlfSfDTj7T/pa7Q4laprDC0jPLXBLVl4ET5q3YYVua/l7ROLiOsRYA+M+xMr1JiFtEvwqqZitz6MKeM02xI= X-Received: by 2002:a17:907:60ce:b0:aa4:e53f:5fbe with SMTP id a640c23a62f3a-aa509a1c2f9mr263083266b.19.1732265374191; Fri, 22 Nov 2024 00:49:34 -0800 (PST) MIME-Version: 1.0 References: <20241117213206.1636438-1-cel@kernel.org> <20241117213206.1636438-3-cel@kernel.org> <20241120-abzocken-senfglas-8047a54f1aba@brauner> <20241121-lesebrille-giert-ea85d2eb7637@brauner> <34F4206C-8C5F-4505-9E8F-2148E345B45E@oracle.com> <63377879-1b25-605e-43c6-1d1512f81526@google.com> In-Reply-To: From: Amir Goldstein Date: Fri, 22 Nov 2024 09:49:23 +0100 Message-ID: Subject: Re: [RFC PATCH 2/2] libfs: Improve behavior when directory offset values wrap To: Chuck Lever Cc: Hugh Dickins , Christian Brauner , Jeff Layton , Chuck Lever , linux-mm , Linux FS Devel , Daniel Gomez , "yukuai (C)" , "yangerkun@huaweicloud.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 058F0180003 X-Stat-Signature: udx6qbmyxu9p7tefyzbgtknknjqkbnze X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1732265337-404465 X-HE-Meta: U2FsdGVkX18grpZK5fKsQehiCwxRNufRM4ZzYmHWJiVrMwAmMHomznbWd+pIS8/l345LoYu4RGt5VByG/hmNWqdubtg/TrIoNO8PVqWPXswlP0CXWYmFgdML1onseHHVhas57I43U3ZN3g5E6vuEO9F+vfxax8lT6pzDGTd0lvXgaKJsFcD+wo74Chc+b9cFJjGOEXikXx20NcWhA1lYPBC3oZnneJxwPSv5KvTtMmAwgMTevpi3AFd5p9cDh2Z7rnfBa7kX005nGadJieb0awEmyyb1iYtwyHF7J1W2f+DR5NJ/wE0OFR4x/ehRRQK00p7vOAi+yDx37408OINItAnWxTkaHooSqBKyt7QwAlpXQTRf/4Hipv0IjE7DmvNot7fqb9AidCkNgXpdu4BMaDEuUGRl1Ufvw/hMjbUhAPipEwI1263g+h2tLIFWSG7djuehtxG9c8h6X9VD64W7aDveQH0iE447UUYe9KCTbYqPVPQLOflnEeatwesp/1/U2mntMN6hd1sy/W/FjMactg0OD4ZfMY2zpaePgrsiTZwlVTlXN7/JBvwiw67ukfS86lD7xoruoAR4HH/3Lybwpljwx9Gd/D7M70/Ul5AC+3Wh03aIykq4YzBuI26LVMcEaPpAVSNAJYkXwGtgbeZ0PtfCs+6AiZq4ANTxsbO2d9TPuvIaz4mAG/Fc/UsElCljiqnZFjMl7kYYBmECrVz/JURD5YO0AA6c4p+Io2gCpbXGQJtKi7tQWAPcEELHqNZcAVK2zwh9OoUG/fxlIOHmwTIY/B8QyAMtCIqHgmzWF0o+zgIqh3DSHHTaK6kyN/93Yb+7jbubZVBUJF0dYco4uLwEja8kDedcwAdNKRwyIk6hilmKzg/8mcqbShrs6LWT8MkhR+yRGZu4jXF9JlYlrQ2d/IOKJqX4aFSWtJd/44Zt2pGYeDoQWU4Llzs2EzubCtV1yeAlH5xy6zFrv+N FrfS4PrM oKOZ2M3jNOAkB2OOEkRwLwgQOnoKWOTnKGxBpU1E+kjea2xImIsPPXB8dKZhXqXyOgvp0JhPCTvHoNM9RaC+is5Dd57UHyZkXh4L1FAQH8t8ne6dwWB7Pbbqmjc9S/lvREJh9edBB2N+mkV0fYqQP0harVB/l+j+TdZ0PptlmAnvs4OpHxAgr7BjJHCMQN3SruOrYlJnyNj9NhKTJga/qINAaJRGIkPhfIcfY4NSTW1srweD8mboh6oQ6cjonkuAr7JXfpFNN9hU9viI+mffTOXDZd51EGutWyyBG5OGYIq5bGnkweVA+KOhXWGBU8vQKLNmXqQ+/hdcDhZhy+XI4oRHoiHPieu/RKLX2pRjokPHnmLRHlPqLV8Z3nq1qPNaMrIcW+rrOYRhQdXxj9gSh2pm7WdV/nO0P6Etg X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Nov 21, 2024 at 10:30=E2=80=AFPM Chuck Lever wrote: > > On Thu, Nov 21, 2024 at 01:18:05PM -0800, Hugh Dickins wrote: > > On Thu, 21 Nov 2024, Chuck Lever III wrote: > > > > > > I will note that tmpfs hangs during generic/449 for me 100% > > > of the time; the failure appears unrelated to renames. Do you > > > know if there is regular CI being done for tmpfs? I'm planning > > > to add it to my nightly test rig once I'm done here. > > > > For me generic/449 did not hang, just took a long time to discover > > something uninteresting and eventually declare "not run". Took > > 14 minutes six years ago, when I gave up on it and short-circuited > > the "not run" with the patch below. > > > > (I carry about twenty patches for my own tmpfs fstests testing; but > > many of those are just for ancient 32-bit environment, or to suit the > > "huge=3Dalways" option. I never have enough time/priority to review and > > post them, but can send you a tarball if they might of use to you.) > > > > generic/449 is one of those tests which expects metadata to occupy > > space inside the "disk", in a way which it does not on tmpfs (and a > > quick glance at its history suggests btrfs also had issues with it). > > > > [PATCH] generic/449: not run on tmpfs earlier > > > > Do not waste 14 minutes to discover that tmpfs succeeds in > > setting acls despite running out of space for user attrs. > > > > Signed-off-by: Hugh Dickins > > --- > > tests/generic/449 | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/tests/generic/449 b/tests/generic/449 > > index 9cf814ad..a52a992b 100755 > > --- a/tests/generic/449 > > +++ b/tests/generic/449 > > @@ -22,6 +22,11 @@ _require_test > > _require_acls > > _require_attrs trusted > > > > +if [ "$FSTYP" =3D "tmpfs" ]; then > > + # Do not waste 14 minutes to discover this: > > + _notrun "$FSTYP succeeds in setting acls despite running out of s= pace for user attrs" > > +fi > > + > > _scratch_mkfs_sized $((256 * 1024 * 1024)) >> $seqres.full 2>&1 > > _scratch_mount || _fail "mount failed" > > > > -- > > 2.35.3 > > My approach (until I could look into the failure more) has been > similar: > > diff --git a/tests/generic/449 b/tests/generic/449 > index 9cf814ad326c..8307a43ce87f 100755 > --- a/tests/generic/449 > +++ b/tests/generic/449 > @@ -21,6 +21,7 @@ _require_scratch > _require_test > _require_acls > _require_attrs trusted > +_supported_fs ^nfs ^overlay ^tmpfs > nfs and overlay are _notrun because they do not support _scratch_mkfs_sized > _scratch_mkfs_sized $((256 * 1024 * 1024)) >> $seqres.full 2>&1 > _scratch_mount || _fail "mount failed" > > > I stole it from somewhere else, so it's not tmpfs-specific. I think opt-out for a certain fs makes sense in some tests, but it is prefered to describe the requirement that is behind the opt-out. For example, you thought that nfs,overlay,tmpfs should all opt-out from this test. Why? Which property do they share in common and how can it be described in a generic way? I am not talking about a property that can be checked. Sometimes we need to make groups of filesystems that share a common property that cannot be tested, to better express the requirements. _fstyp_has_non_default_seek_data_hole() is the only example that comes to mind but there could be others. Thanks, Amir.