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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FBD7C07E95 for ; Tue, 13 Jul 2021 20:18:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0071161351 for ; Tue, 13 Jul 2021 20:18:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234665AbhGMUU5 (ORCPT ); Tue, 13 Jul 2021 16:20:57 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:36227 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S231499AbhGMUU5 (ORCPT ); Tue, 13 Jul 2021 16:20:57 -0400 Received: from callcc.thunk.org (c-24-1-67-28.hsd1.il.comcast.net [24.1.67.28]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16DKI14s028545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jul 2021 16:18:02 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 47CE34202F5; Tue, 13 Jul 2021 16:18:01 -0400 (EDT) Date: Tue, 13 Jul 2021 16:18:01 -0400 From: "Theodore Y. Ts'o" To: Shyam Prasad N Cc: David Howells , Steve French , linux-ext4@vger.kernel.org Subject: Re: Regarding ext4 extent allocation strategy Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Jul 13, 2021 at 06:27:37PM +0530, Shyam Prasad N wrote: > > Also, is this parameter also respected when a hole is punched in the > middle of an allocated data extent? i.e. is there still a possibility > that a punched hole does not translate to splitting the data extent, > even when extent_max_zeroout_kb is set to 0? Ext4 doesn't ever try to zero blocks as part of a punch operation. It's true a file system is allowed to do it, but I would guess most wouldn't, since the presumption is that userspace is actually trying to free up disk space, and so you would want to release the disk blocks in the punch hole case. The more interesting one is the FALLOC_FL_ZERO_RANGE_FL operation, which *should* work by transitioning the extent to be uninitialized, but there might be cases where writing a few zero blocks might be faster in some cases. That should use the same code path which resepects the max_zeroout configuration parameter for ext4. Cheers, - Ted