From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 18840380FD6 for ; Thu, 20 Aug 2026 15:19:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787239156; cv=none; b=qrRcBeXis5RIr/mxFdc2ULKU1/D0dPbeoUapFfq4SfopGte+4XQv7q+fyCsm9jKwCCLleyzM4AvNkGZCxTBDYYv2IOM4UBtOB4mtNHrAxl5U7L6PdTrS17iRr+1wbo3kn/MI/nRwwmFdXVOtxkDtf/TUIL5TV0xDMxM8pBNQB2k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787239156; c=relaxed/simple; bh=8RqABrvlJokOUj6jhqU8frU6nTSmn/toVzxIzcthQNI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aV7XxZLdFgTS+ZNHlvSehuN/qXP8CHA03qRrDD/PeYjxNHzHwC+a1e3xZyX8EvkXYSGCTcQcxdB+nDSx7vubiiT3OQFvMSJToPs/wlQQ2wpHoxRMwGjijl4hwSU1VnNGc2Sa6z3P80ZyxtSF9TTXzFG1Yins6sXp3gKu1URMRVE= 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=Q0VVDb3+; arc=none smtp.client-ip=209.85.214.177 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="Q0VVDb3+" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2ceab75934dso28715785ad.2 for ; Thu, 20 Aug 2026 08:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787239154; x=1787843954; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=a7ZM3S7YxfSumzIgj8EPnrdkbPiZ22RqFoPFkb521tU=; b=Q0VVDb3+nYFdrjd4ZdtVrY0Eafa4FUQbI1IfjTpOFAMKgbLvdQwK7le3X/1mffYx3s 8JgNWQULMjYeXGt/Ut6YsPcH/H+ERs+U46T53tEkri7+IbBm3ndUS+1jYyan0sqCzXAy 31b7Kf0RvMj/sQdV86sgxMe2jZzqtXGzRBr2T6tFk8WKY6bfiOZB4mhhF98dRi4x/ZHk QxS+T7SCCb1iz2T8KTFWwzTbFE2XDRyGEVKFbSfYfvb3lLoskQukkJtC82zGuYTI97vX FqJnfQZR89b0jnyq9vuitjATs+D+c9DtjC2zXonRktu198t01hiM7ZCnoHkpK2kUNLi2 k8Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787239154; x=1787843954; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=a7ZM3S7YxfSumzIgj8EPnrdkbPiZ22RqFoPFkb521tU=; b=d0RXNLDBD78TrIrmcYPkFFDTwAbpWRJ9KJKfTQvjSKLQvMIcmM5JG+++Acmay/oXib PCx2Q/N6xFF2LjSIRHzzayiR6E1Hk/tbFT4xyyUgvG9lPbLDdbw5o8j7Wvxji+geWapD KVBWraILrgT761j975LR+7Uy9kuDm/ErWStdHDeXLKBSrLfUWt7DNTTblkRXZpI5+ZUA eV0XmBsHPMoj6BHNKxPvYl7J0wLgOZV5GFk8GHp8wcutwg2Schq4LYc7EzO8bqeYk9Mc uJsJ6GgCys24ZJ9PHIAc6QMhUXGz6H75h89cvkYcYgntlabi6mnl0k825yVrAhxN9Fcc xV9A== X-Forwarded-Encrypted: i=1; AHgh+RrXdekRXVD2P9k/mox/5B6FP8xyNfaM/hYZ9mdvE895OCGmMWRd9gEkJi8nylt+9iFyP8YnJ7IlTa0/2zo=@vger.kernel.org X-Gm-Message-State: AFuF++nAo4leHRhplGAVjhBzjYwsK2Xzka7Ptzimw42HzNTYO/w010lC qnYhnG+q3jc4wRxOLrN6b5Echs4Vmm5PsvFVRIg0SmnLbDKVx29xrdEV X-Gm-Gg: AR+sD10dq6gfTMVnymgwVhWPrLxWE0rdZLiJJ2iPeMx2D6TvAxLK8domJp5lTcxKaVg qRCvpPy5dnvtXI7yC/VaMPTj/6IEho31wHXR2bfZ4rIEHTqI925KL+IGMZkQuIONW4cK1dHDQ78 cYArO7P1gjxsHNQe/JOIEUXmO+bkwQetYMdU+N/+oQsPEbe3n/V/CHbywtq/WY5HastoVLKo6O5 nG2MXxCgHJUBBbpy62N0Kldbos4V2jYk6v/3hATw6UdAjbx7uR7G6SjBg69OgjdO+b1j5yk3IR6 bQKutV9o+Gj3O3ZO2ZkGUtMCmoFea1u+lwx4tvzFbD0JvZEb6djs2elecWFOcem49XB+xMAkjCy ieuWujqK3+XWsP9Ku9jiDtS8uNzT3xxAwjB+3HrnDNfBvsMed+hJImuLQVZVcisZ7iptnccXhA/ 54k0IV3ZmfHZTm+kTsZRyjJZkzCITeGNYOp5RGvHIhi5EIFMlcRgqPr9g3BdLbiLGAfl8CWTytO GDrDQBn X-Received: by 2002:a17:903:b8c:b0:2cf:4c0f:5127 with SMTP id d9443c01a7336-2d5fd6a3fa5mr267331825ad.10.1787239154226; Thu, 20 Aug 2026 08:19:14 -0700 (PDT) Received: from [100.125.248.95] ([124.70.231.46]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d62e3affeesm8394785ad.65.2026.08.20.08.19.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2026 08:19:13 -0700 (PDT) Message-ID: Date: Thu, 20 Aug 2026 23:18:59 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] ext4: orphan tracking after a failed truncate To: Theodore Tso , Zhang Yi Cc: Jan Kara , Guanghui Yang <3497809730@qq.com>, Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org References: <66vcv4ircw5mqadt4eki52hujmykrrsqp2cux4qvn37v6kzvs7@d7ys45emz3dr> <1537a281-aa34-49f8-87f1-e5f4fab8eb10@huaweicloud.com> Content-Language: en-US From: Zhang Yi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/18/2026 9:48 PM, Theodore Tso wrote: > On Tue, Aug 18, 2026 at 12:41:57PM -0500, Zhang Yi wrote: >> I think we might want to add a small qualifier here: this is only expected >> behavior under errors=continue. For the remount-ro case, we immediately >> abort the journal to prevent writing out inconsistent metadata after an I/O >> error, which helps contain the damage. So after journal replay, the file >> system should still be able to maintain a consistent state. > > Errors={continue,remount-ro,panic} only apply if the ext4_error() > family is called. The problem is that ext4_ext_remove_space(), which > is called by ext4_ext_truncate() calls read_extent_tree_block() and if > it returns an error, it returns EIO without actually calling > ext4_error(). So the truncate system call will return EIO, with > i_size set to zero, but with blocks beyond EOF still left allocated. > I checked the code. Apart from the verity path, all callers of ext4_truncate() already call ext4_handle_error() when it returns an error. So it doesn't look like there's any issue with truncate at the moment. So I suspect that Guanghui won't be able to reproduce this issue in remount-ro mode, and I'd suggest that similar consistency tests under fault injection scenarios should all be run in remount-ro mode. > As I menstioned, that's not _fatal_ in that case, since blocks beyond > EOF can happen with fallocate(2) with FALLOC_FL_KEEP_SIZE. But it > could be a bit surprising, since truncate return an error, but the > file was actually apparently truncated (or partially truncated, in any > case). > It seems we can't guarantee that the file being truncated is always preallocated. If the blocks were already in written state, then after we update i_disksize to 0 but there are still blocks left unreleased, fsck will still complain, Did I get this right? Best Regards Yi. > We could change it to call ext4_error() which would signal the system > administrator would get a clear signal that she should run fsck, but > in terms of bugs, it's not as serious as if the file system was left > actually corrupted. > > Cheers, > > - Ted >