From nobody Sat Jul 25 02:11:49 2026 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD3193DCDAB for ; Mon, 20 Jul 2026 14:19:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784557201; cv=none; b=L3ZzWke8ccdH3JtHCpEuQq+lNrjqTOJc4rPo34cotoPEhtOIUBv/VQdBvvtjb97GC/pUpDBUEtzTqQw2YwcrvYZXE+8PvO3pkJ669Q3xpGOBMAvtMiunP1jgtJky8jXMfaabWqiVvcndNoBIDLswVmhdlnFQiHpGI4pR/MqEgrA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784557201; c=relaxed/simple; bh=oaAbz8G8f2X7RTP1P1HJ+1cflrmoJylc1nG/N2BbeVM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=t+yXXqs/TYcX9+dR+ajKRbM0//MDl9rf0/W6vBYuIhpbnq4fogd3HW+F8T88I7eSTY7rgxgsdZhK92pyIT11isAn+zI7BNvjyMPH3vbuy+fDd4jxuMalZ23VUl9F0ujGoF0qcBfcY/g/ne3MU7ZqLH3BGBa9vxPX+LewqEhjz5k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nbyLo2jO; arc=none smtp.client-ip=209.85.214.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nbyLo2jO" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2cc97653887so111392535ad.1 for ; Mon, 20 Jul 2026 07:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784557199; x=1785161999; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=e7d4MGOSniHAE+Fyu0H72S0OaeGQ/IROc3PriVSjYUc=; b=nbyLo2jOpFBfTzSVeSrPMMLa9KeAXX/OPxrti2zHvQu9CeIm/9LSi5BpbMa12v3KLh 9/IUBkOiuLV7va3AroG5QXw23uvrYCCiBER4eQVcE68uqQ/Qo5KieKMSZm8DZG6F0ITJ HOT83Iv51e4jXaiXmdROim9OLlP4TsxM0ZO3fiHFBEgpYhcg9C/P0HENx01A8in05spY /8Tidune3B9pSNx4GbMHuJK2BAp80EM1U5wCWajjrG6fQ5wK4kjo1AHAUly3fK71/UNE XeMDEMO0xz0CCz6AinZKnCpOFvwhD44Ck2Z8/ynuL48WZIxl4XfXVm3KyZAsxVyjN+ro HL6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784557199; x=1785161999; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=e7d4MGOSniHAE+Fyu0H72S0OaeGQ/IROc3PriVSjYUc=; b=D2Z+1KG91vNWCdo7NqCodALSBLiBzMQ7UpJQnuNZ0BZTTJDKx2WtjyOZ9k0RD2GsDM UvHz/O8ypYJgaqCe4QFLbb4/bD26iroJssN9djVvon1QHXjxp8iylz3wT4RJ5z/lcjqZ cHj/HFKhfjXWUdCy9iOvj++n8kqQK8IOjMRjKYqGYfsyvxIJVAwXUZNyWNpra5pBOjv7 V0GhdfrPnufekL0EdPW6BbGNzORQUCSAmq9hs3RF4yIfmWZdAymHV6fPkWykDMvJXzXw RV7b2nzfitbl65wQqLt+t3gistHFLRPnT3gILqBLH6u0s3gsalFocj3RBBbsjbqxhprQ Auvw== X-Forwarded-Encrypted: i=1; AHgh+RpbIuneJ2PQFAxy2F7jKa+FB5cOoL8GGYIO0hxuBUlVaBuMRH24hXLzsRAdxH/RU8wcbkcPJLTO9oWhuqs=@vger.kernel.org X-Gm-Message-State: AOJu0YxNwibsbNG8PPlgxqWxayWUCvWNjhj9TwGQAP4CLzACunVZpa8x KnMVLm+tSbw77o5G7CnDVqanK00TvsqDeqP1mRZ7VvgoeWYzJr1XVFIR X-Gm-Gg: AR+sD11LyphJaiOYNPJWPDIeWgMqZ95KPp5zQ3qART1npLJOnN+SP26cq7y3WsJQIok 0X4IS4G6c988IWDZpMYkr6LHFiR9c/O33BIvxTwb3NqYVVQFRllpcVOmTzFzDmwGBP5Zm40GMtH da74Al/rVi7OzISOJVtw5BGCH6i0LAUGJS8UdcDlmAW+HGyHxdi2GsI+3oyr4CjpYlKaEzLo27I bFThePu56wQgaRYPvprQbiXI2q5XfXkY4/AJ2VdK8+wchH2LQIoSVI7qIDs78ElhYMagMHzEqU7 Kqa2XLkOd7o2/bAFUTHL1iZdebbno4VMAb8IveIa65JoVYr+UPaBOVgNxT1VQA2cwEVqCwgft5Y NNkq3HEfSXLD2v42iI0hBK8AJ8y5C7gVEvOH82vE4iZx0+8vArObayPJ5UTPzWSI9rpgL0Cx77c E= X-Received: by 2002:a17:902:f710:b0:2cf:7d44:e14f with SMTP id d9443c01a7336-2cf7d44f558mr4954095ad.26.1784557198961; Mon, 20 Jul 2026 07:19:58 -0700 (PDT) Received: from lgs.. ([101.76.249.46]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cf3479463bsm56844765ad.80.2026.07.20.07.19.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 07:19:58 -0700 (PDT) From: Guangshuo Li To: Mark Fasheh , Joel Becker , Joseph Qi , Tristan Ye , ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org Cc: Guangshuo Li Subject: [PATCH v3] ocfs2: free unused clusters on defrag move errors Date: Mon, 20 Jul 2026 22:19:43 +0800 Message-ID: <20260720141944.485212-1-lgs201920130244@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" ocfs2_defrag_extent() claims new clusters before calling __ocfs2_move_extent(). If the move fails before ocfs2_split_extent() succeeds, the claimed clusters are not referenced by the inode and must be released. The current error path only logs the error and continues to ocfs2_cow_sync_writeback(), which can overwrite the original error with zero and leave the claimed clusters allocated. Not every __ocfs2_move_extent() error can free the new clusters. Once ocfs2_split_extent() succeeds, the extent tree references them even if ocfs2_decrease_refcount() or ocfs2_truncate_log_append() subsequently fails. Freeing the clusters in that case would leave the extent tree pointing to clusters marked free. context->new_phys_cpos is updated immediately after a successful extent split. Compare it with the newly claimed physical cluster on error. If they differ, the split for the current move did not complete and the claimed clusters can be freed. If they match, leave the clusters allocated because the extent tree already references them. Return move errors through the transaction cleanup path so that the original error is preserved instead of being overwritten by writeback. Fixes: 202ee5facb2c ("Ocfs2/move_extents: defrag a range of extent.") Signed-off-by: Guangshuo Li Reviewed-by: Joseph Qi --- v3: - Fix the duplicate split_started declaration. - Reuse context->new_phys_cpos to determine whether the extent split succeeded, as suggested by Joseph Qi. - Avoid changing the __ocfs2_move_extent() prototype. v2: - Do not free the new clusters after the extent-tree update has started, as pointed out by Joseph Qi. - Track whether the new clusters remain unused on error. - Preserve __ocfs2_move_extent() errors instead of allowing the subsequent writeback call to overwrite them. fs/ocfs2/move_extents.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/ocfs2/move_extents.c b/fs/ocfs2/move_extents.c index ad1678ee7cc4..7820df90a262 100644 --- a/fs/ocfs2/move_extents.c +++ b/fs/ocfs2/move_extents.c @@ -310,8 +310,12 @@ static int ocfs2_defrag_extent(struct ocfs2_move_exten= ts_context *context, =20 ret =3D __ocfs2_move_extent(handle, context, cpos, new_len, phys_cpos, new_phys_cpos, ext_flags); - if (ret) + if (ret) { mlog_errno(ret); + if (context->new_phys_cpos !=3D new_phys_cpos) + need_free =3D 1; + goto out_commit; + } =20 if (partial && (new_len !=3D *len)) *len =3D new_len; --=20 2.43.0