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 C6A2619F461 for ; Mon, 21 Apr 2025 16:30:57 +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=1745253059; cv=none; b=pLsR+gchmACm551zz1Ii8HzcgsFzYJQNmBL3LIlHXxjsAUsLVE+RuaAEL4UF5i/VD6PGWz14DA9hXkpMDakiHmYEsbYyWDHadHRfI0ciw8ToHZcPaFgxzOCWNn9uR0mQdChahdtfhNMkXMwkEhprXwHBXbN64CGfYhEa31tatrM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745253059; c=relaxed/simple; bh=IFBrOGhuz5lZXdQiE1OfbkxzUlOYhSK+LBKZ54Y1NeM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fmHmIl7DQdWe53wXl80jMWB8RoP77RcmhXZu1eBDu2kBArrbP0D9+SO8hmPfkRSWFo3Q/2yxiT3m6t32mUpIdqnCHHTljKOaA+cCwg9wqRUjyUOTVOIP2UFJZ1NnZLrWYg+9lrwGSZeJGpeS6sXc0eg4XO6ltRtYGiEYKKkn4pI= 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 ([204.26.30.8]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 53LGUX5m011561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Apr 2025 12:30:34 -0400 Received: by macsyma.thunk.org (Postfix, from userid 15806) id 7F9B73463AE; Mon, 21 Apr 2025 11:29:52 -0500 (CDT) Date: Mon, 21 Apr 2025 11:29:52 -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: <20250421162952.GC569616@mit.edu> References: <20250416233415.GA3779528@mit.edu> <20250417163820.GA25655@frogsfrogsfrogs> <20250417183711.GB6008@mit.edu> <20250419182249.GC210438@mit.edu> <20250421155433.GC25700@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: <20250421155433.GC25700@frogsfrogsfrogs> On Mon, Apr 21, 2025 at 08:54:33AM -0700, Darrick J. Wong wrote: > > I might be wading in deeper than I know, but it seems to me that > after a crash recovery it's not great to see 64k files with no blocks > allocated to them at all. Well, what ext4 in no dioread_nolock mode will do is to allocate blocks marked as unitializationed, and then write the data blocks, and then change them to be marked as initialized. So it's not that there are no blocks allocated at all; but that there are blocks allocated but attempts to read from the file will return all zeros. This is non-ideal, but my main concern is a performance issue, not a correctness one. We're modifying the metadata blocks twice, and while most of the time the two modifications happen within a single transaction (so the user won't actually see the zero blocks after the crash _most_ of the time), the extra journal handles means extra CPU and extra jbd2 spinlocks getting taken and released. So it's on my todo list to fix, in my copious spare time..... > (I don't care about the others whining about _exclude_fs-- if > you make the design decision that the current ext4 behavior is > good enough, then the test cannot ever be satisfied so let's > capture that in the test > itself, not in everyone's scattered > exclusion lists.) Fair enough, I can try, and see if we get people attempting to NACK the changes this time around. Support beating back the whiners would be appreciated. I can also see if Luis's LBS changes might it easier to deal with the bigalloc test bugs. It will mean exposing the concept of cluster allocation size (as distinct from block size) to the core xfstests infrastructure, and again, we can see if people try to NACK the changes. This will require a bit more work, however as this is a big difference between XFS's LBS feature and ext4's bigalloc feature. - Ted