Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp880102rwb; Mon, 26 Sep 2022 07:04:09 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5aC48y7Wdx/gwHVzokXNu6PR/WF8r54Nrw7u01QNllnR8qDb7lonKX56fSTkTxnUhvTO+L X-Received: by 2002:a05:6402:26d6:b0:451:24da:f8cf with SMTP id x22-20020a05640226d600b0045124daf8cfmr23069470edd.385.1664201049356; Mon, 26 Sep 2022 07:04:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664201049; cv=none; d=google.com; s=arc-20160816; b=nou1bth/zNmw1bJSRLTfNLX4CUBqzjJ2kNX7mV0eaKysb2PsYmLsg2Vq0VjzSM/LTW MNrZHTK7chsi6Srq1QmRYs+Iryb0R0vEI0dPPj3WNIucxdgx630rZgE3tPOuUilaFAJQ FEIT/SYtxaJn4mKvAkAKdUs6r8+wNO5wbgN4UGQcIjXx2NvVaR21/dUq212MJFRzVusg /GVZMpxezrZkCJDR3jFu3jmXgusnXtcc9JvMvCQNZV2A4yvWdsJtWCuv51vNIx+wT6WN 1gxM+C9km8sRlRJ1Crm/RBlLSozoAVwSrTkbdmGrIl3oygs3dz0Esb4mYaNJ4u7HlNy9 4LhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=J0g9IAGFFbYLJYVYdqP3TJBrSh4ciVWztrI8hu/Rt6A=; b=QdclLLnbuQl6ZM/a40kILW6RUdsOGUkxLBEbVazU9D+irn/e7Pr7Oy1L7oe58QjT2q JAwqlKD6RqNbCKGHEd1OkaUCRyk5aLkNM5rzqHlxuPkxU8661mouvlNWI1iUH9DFNC1l LqcpQW1BYWO2uV5zXyi+pDnFn2ekcsAj5g/UIeaNpxwrbwgiVAQkNujAVhJXb6fQyUR7 0buGTSwsL2sIqVHyzaVLNm3X+21mBqBLyDWS/vQpeQoJ8FNkT08WpzvNp0n8J+RnNWwq EFli0u5ipiR5ri3+4+XYX5mkvb5xURj8PRmAFBmbzo08n0Hce0ZfaRjsuli6wJUw5chM cXmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=MCOz3hd1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id eb5-20020a0564020d0500b00451ecf8c2fasi18419271edb.394.2022.09.26.07.03.42; Mon, 26 Sep 2022 07:04:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=MCOz3hd1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239171AbiIZMCx (ORCPT + 99 others); Mon, 26 Sep 2022 08:02:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239129AbiIZMAG (ORCPT ); Mon, 26 Sep 2022 08:00:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54A827C32D; Mon, 26 Sep 2022 03:53:09 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F202C60C94; Mon, 26 Sep 2022 10:51:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB653C433C1; Mon, 26 Sep 2022 10:51:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1664189509; bh=wKQ2OWT+iKaWQAMG/hdsCIYwXywAu5qK/bsiXG5dHtM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MCOz3hd19eOMl2lTfU+SVmbz9fXa/W/6lpWvSWMWcnchpTjkIoYznEUxoe8NT7izu FbgwM5DYl/oP55/za3pSe7vZZz/u73bczykpWCXs0LDAWEG/CGEi4cCRB4rifGKI6j HNWD/jhPZRh0om+Bl7/PlzcL2cb56z5+Yi+gWhMQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Ojaswin Mujoo , "Ritesh Harjani (IBM)" , Jan Kara , Theodore Tso , Stefan Wahren Subject: [PATCH 5.19 205/207] ext4: use locality group preallocation for small closed files Date: Mon, 26 Sep 2022 12:13:14 +0200 Message-Id: <20220926100815.787405954@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220926100806.522017616@linuxfoundation.org> References: <20220926100806.522017616@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jan Kara commit a9f2a2931d0e197ab28c6007966053fdababd53f upstream. Curently we don't use any preallocation when a file is already closed when allocating blocks (from writeback code when converting delayed allocation). However for small files, using locality group preallocation is actually desirable as that is not specific to a particular file. Rather it is a method to pack small files together to reduce fragmentation and for that the fact the file is closed is actually even stronger hint the file would benefit from packing. So change the logic to allow locality group preallocation in this case. Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren Tested-by: Ojaswin Mujoo Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Jan Kara Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Link: https://lore.kernel.org/r/20220908092136.11770-4-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/ext4/mballoc.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -5189,6 +5189,7 @@ static void ext4_mb_group_or_file(struct struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb); int bsbits = ac->ac_sb->s_blocksize_bits; loff_t size, isize; + bool inode_pa_eligible, group_pa_eligible; if (!(ac->ac_flags & EXT4_MB_HINT_DATA)) return; @@ -5196,25 +5197,27 @@ static void ext4_mb_group_or_file(struct if (unlikely(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY)) return; + group_pa_eligible = sbi->s_mb_group_prealloc > 0; + inode_pa_eligible = true; size = ac->ac_o_ex.fe_logical + EXT4_C2B(sbi, ac->ac_o_ex.fe_len); isize = (i_size_read(ac->ac_inode) + ac->ac_sb->s_blocksize - 1) >> bsbits; + /* No point in using inode preallocation for closed files */ if ((size == isize) && !ext4_fs_is_busy(sbi) && - !inode_is_open_for_write(ac->ac_inode)) { - ac->ac_flags |= EXT4_MB_HINT_NOPREALLOC; - return; - } - - if (sbi->s_mb_group_prealloc <= 0) { - ac->ac_flags |= EXT4_MB_STREAM_ALLOC; - return; - } + !inode_is_open_for_write(ac->ac_inode)) + inode_pa_eligible = false; - /* don't use group allocation for large files */ size = max(size, isize); - if (size > sbi->s_mb_stream_request) { - ac->ac_flags |= EXT4_MB_STREAM_ALLOC; + /* Don't use group allocation for large files */ + if (size > sbi->s_mb_stream_request) + group_pa_eligible = false; + + if (!group_pa_eligible) { + if (inode_pa_eligible) + ac->ac_flags |= EXT4_MB_STREAM_ALLOC; + else + ac->ac_flags |= EXT4_MB_HINT_NOPREALLOC; return; }