From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DDBF2571CF for ; Thu, 17 Apr 2025 18:37:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744915042; cv=none; b=TP7C9fv9D/ISt1lS+2z+UFzYlHDztFEmkABqFBU2IaRZU9lO87hHBFth1d0y74TB1t6sfC7EiYr/bm/mxnyWZalhyiLAGvWyVb86Oqo/yXClOBvvZ1xw1rPiD/j92LL2sTosOP3p3CpTxrzcHE1FbAPL9DABBeUf8n9nSWsOnvg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744915042; c=relaxed/simple; bh=7/TYR7hjxw8uI7CKx4Li6ruOBe6Uxmmo1zXWVc4ImzY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=D0I1rP2vIya6RlnUVpfMclJBBYHJus6+qOCQg2ECtwyqNah6tbR6T25uZiq9dDaOcymKJuHApbnKV3vNZKUYmpo4tVCtWe8g+Up6wz3cGB432zaSLQFtTfcFlbh8AbVMc7gHeGI9iamCAN9k6Ic8CkT++jAcm5jlVgTwjVxZjmk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Received: from macsyma.thunk.org (c-73-9-28-129.hsd1.il.comcast.net [73.9.28.129]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 53HIbBa8025010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Apr 2025 14:37:13 -0400 Received: by macsyma.thunk.org (Postfix, from userid 15806) id 302F2340A4B; Thu, 17 Apr 2025 13:37:11 -0500 (CDT) Date: Thu, 17 Apr 2025 13:37:11 -0500 From: "Theodore Ts'o" To: "Darrick J. Wong" Cc: Luis Chamberlain , adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, kdevops@lists.linux.dev, dave@stgolabs.net, jack@suse.cz Subject: Re: ext4 v6.15-rc2 baseline Message-ID: <20250417183711.GB6008@mit.edu> References: <20250416233415.GA3779528@mit.edu> <20250417163820.GA25655@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250417163820.GA25655@frogsfrogsfrogs> On Thu, Apr 17, 2025 at 09:38:20AM -0700, Darrick J. Wong wrote: > > generic/04[456] fail with a bunch of... Yeah, this is known. I have an ext4-specific exclude file: // generic/04[456] tests how truncate and delayed allocation works // ext4 uses the data=ordered to avoid exposing stale data, and // so it uses a different mechanism than xfs. So these tests will fail generic/044 generic/045 generic/046 > ext4/043 seems to fail because it tries to create 128b inodes with > project ids and fails. Yeah, I don't enable project id quotas by default in my test setups. And _scratch_mkfs will fallback to using just the tests's mkfs option, so if -O quota,project are specified in MKFS_OPTS, then the fallback works: Start test timestamps with 128 inode size one device /dev/vdc ** mkfs failed with extra mkfs options added to "-q -O quota,project" by test 043 ** ** attempting to mkfs using only test 043 options: -I 128 ** I suppose we could explicitly add something like -O ^project to the test, but enabling -O project isn't in the default e2fsprogs mke2fs.conf, and there are probably all sorts of oddball mke2fs.conf configurations that might cause tesets to fail. > ext4/053 I suspect fails because built-in quota conflicts with the quota > mount options. Hmm, I can't reproduce this with "kvm-xfstests -c ext4/quota ext4/053", which will configure xfstests with: MKFS_OPTIONS -- -F -q -O quota,project /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o block_validity /dev/vdc /vdc Can you send me the out.bad and full files for that test? Hmm... maybe this is another one of these "it fails if a non-standard mke2fs.conf is used, although I don't see how." > generic/{633,697,696} fails with: > > --- /run/fstests/bin/tests/generic/697.out 2025-01-30 10:00:16.953276275 -0800 > +++ /var/tmp/fstests/generic/697.out.bad 2025-04-16 15:54:39.173837150 -0700 > @@ -1,2 +1,4 @@ > QA output created by 697 > +utils.c: 928: openat_tmpfile_supported - Invalid argument - failure: create > +utils.c: 928: openat_tmpfile_supported - Invalid argument - failure: create > Silence is golden > > No idea what that's about. I don't have any idea either. I assume there's nothing in the dmesg for that test? Those tests are passing for me, so I got nothing. - Ted