From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 A22B8C8EB for ; Wed, 11 Feb 2026 13:38:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770817112; cv=none; b=TIwGW+vd488GdRHsxkXgDeaxNaQ9784mYvw7Yy5QdsPEn2VPGTZ89nudAOnANONWKPEecq0ZnRSwTPy2nful4UcXcc5kvsIu8MNbJFoNpMAT4Rs5vsptRsoIZvSK7OmcVAkAg9ypfPiIa+g6qoEIzz7GR9GDajTIpl+2CIQ2vnM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770817112; c=relaxed/simple; bh=3kr/X7EVzbCTl45y7tiiOecsEIRUyFN7X9DQHGs+Djw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FaWYjGhVRFvkCIu2QDflHvQhQDb+iBm5H4wDD1Pa1hlQcDYkUJbwnAD2NN8qldMJjmiXrqwE0V6GuzoBUr8qTejvvzKy6KlENH37HWQY+OwCMjedS39lavGiKiv+N3PUYr8oq27UnEf2Vd2dG0ru32lEWhiXKrhzlHKbTdX1lv4= 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=AHkWlHHr; arc=none smtp.client-ip=209.85.214.169 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="AHkWlHHr" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2aad1dc8856so27415745ad.1 for ; Wed, 11 Feb 2026 05:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770817111; x=1771421911; darn=vger.kernel.org; h=content-transfer-encoding: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; bh=CMvjs/DsalGRLabtIAjuej/4mud68+thdemO/4XZvPQ=; b=AHkWlHHrzG1//Ut+UL6Z/5E5mMAMvYW8I+7ejd9FiSADgrDion4MpMHIpZ/quKVck0 fH6id4FvXkKgcjrMSv17i78K/uqgNRZbvg1FBS3JzyoGjUOW1/WIn9QFC7NocLkBD/kL EU1sCrDWp/iagvsU9HaTf9bX6uu4BC5hOUL6e45yHN8qTTDXFVV3bbpTJTYrqJiEBASl d5Hiy4AXu5mTVVTKJE3C0c2ViH6h1uFsI9q51cAC049vIrQnaF0Xkznuaju3T3P6qVmX dmRKE/+pvOl0nQuq2aPwDYa9g1aSrRuVHDSYW01ylFD16Yr5g3nXz7DFv+7SNT20ROY5 kwcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770817111; x=1771421911; h=content-transfer-encoding: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; bh=CMvjs/DsalGRLabtIAjuej/4mud68+thdemO/4XZvPQ=; b=fV2Ugp/WZsIJ0yep5DbaM0BmIAIdajZ0A+cdzqbAgp+jtZlbdQd25z8lBlo+t0eOCj fwH8qFJ+bWlMaA4jSpPk5bkKdFhEfPNNsPNTnGroFknW8pDFsxYg/c4ueJayjl+ApLa1 yphaawH8QUm/hSCt6v+elpgTW8lMyog/91x0gEVz7bmjL/lyuONJfh7YnVWcy2vRQ/56 Sxosb/JiwQpf7pGNk03D+EwRAXGDKkVd75HxrnzRfg3RG4bYUzh3re2tUNtRhJh7lW+C dx5Cc1ToKUtRML7On71tJCldLO8+/xWPgJU95KJsubMgj9al4493rmA7m/27nJ//ufTE L1kA== X-Forwarded-Encrypted: i=1; AJvYcCWIoO+Tl5rmIe/ZLeELStu5Y5Ym6McCdYeohs6aFD8BR16ugbZWHXsV6jnLnIux2ZzT3GGi33vAEXEIsmQ=@vger.kernel.org X-Gm-Message-State: AOJu0YycCnzxgcMbXMN2BgSFzz1yupSZyCAQkAfB93yt+l9EgDqfQwPu LvZFdWtr91UGHDCiCOqujHnP33T9Qmdzr9OQY82A3sopBI11oSAKCBFS X-Gm-Gg: AZuq6aLRxzRj1/3Y6otsvSOh6AJZPlureCdGEU9Hj9Y2NHnG1atRJ3RMEPY9VeUMfiG DlM36sgPwIC6mpNPsgcKv3FWvy7TwL15HEiZeOtsjbOi0XnUT5sJrZa8IzdHG65Yo2JD/9eiKvg htIMg7g3W/EeQk31yAh8WaS+ERfhrDRuUH9y/bfSka2TRxpq9ikd9sMSm0+KxT86ExZIiDRmC9a HJPXtGko3FVifd7DNvXen64FJ7WK70z9umiO/706wUhjMNWsQmq1fJdsF7NrhOKWUT25c5982Bn I3WvDYe2Vnk50L0Yn0qu69OJCTtinHhI69c39YMgigZY+CvcZGReNW3Jifj+yOX1sGC6fyQx8ou JdAJb+XpFYlLqy4kJkXX6LddSwtbjzd/ENs/alce8IMrYbmZrrSlAFVZ1tNyJ/nseep550mI+zh vefEZy1ALx8t5AcedyuORBzudRQcFEexUJAId/wTjY3DMGVfZKF2/0RXqgBdo7j0yy1uTvqs5O5 A== X-Received: by 2002:a17:902:ce90:b0:2a9:5c0b:e5d3 with SMTP id d9443c01a7336-2ab278045ebmr24703725ad.20.1770817110987; Wed, 11 Feb 2026 05:38:30 -0800 (PST) Received: from ?IPV6:240e:390:a90:6d21:e579:6116:b665:1484? ([240e:390:a90:6d21:e579:6116:b665:1484]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ab2984c0d8sm28723825ad.13.2026.02.11.05.38.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Feb 2026 05:38:30 -0800 (PST) Message-ID: Date: Wed, 11 Feb 2026 21:38:23 +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: [PATCH -next v2 03/22] ext4: only order data when partially block truncating down To: Jan Kara Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, ojaswin@linux.ibm.com, ritesh.list@gmail.com, hch@infradead.org, djwong@kernel.org, libaokun1@huawei.com, yangerkun@huawei.com, yukuai@fnnas.com, Zhang Yi References: <1dad3113-7b84-40a0-8c7e-da30ae5cba8e@huaweicloud.com> <7hy5g3bp5whis4was5mqg3u6t37lwayi6j7scvpbuoqsbe5adc@mh5zxvml3oe7> <3ea033c1-8d32-4c82-baea-c383fa1d9e2a@huaweicloud.com> <665b8293-60a2-4d4d-aef5-cb1f9c3c0c13@huaweicloud.com> <3dv6rb4223ngpj2duqm5smvmlpwhbvgyiksfkzmyfxhchejgon@eoo2kitdbdpq> Content-Language: en-US From: Zhang Yi In-Reply-To: <3dv6rb4223ngpj2duqm5smvmlpwhbvgyiksfkzmyfxhchejgon@eoo2kitdbdpq> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/11/2026 7:42 PM, Jan Kara wrote: > On Wed 11-02-26 00:11:51, Zhang Yi wrote: >> On 2/10/2026 10:07 PM, Jan Kara wrote: >>> On Tue 10-02-26 20:02:51, Zhang Yi wrote: >>>> On 2/9/2026 4:28 PM, Zhang Yi wrote: >>>>> On 2/6/2026 11:35 PM, Jan Kara wrote: >>>>>> On Fri 06-02-26 19:09:53, Zhang Yi wrote: >>>>>>> On 2/5/2026 11:05 PM, Jan Kara wrote: >>>>>>>> So how about the following: >>>>>>> >>>>>>> Let me see, please correct me if my understanding is wrong, ana there are >>>>>>> also some points I don't get. >>>>>>> >>>>>>>> We expand our io_end processing with the >>>>>>>> ability to journal i_disksize updates after page writeback completes. Then >>>> >>>> While I was extending the end_io path of buffered_head to support updating >>>> i_disksize, I found another problem that requires discussion. >>>> >>>> Supporting updates to i_disksize in end_io requires starting a handle, which >>>> conflicts with the data=ordered mode because folios written back through the >>>> journal process cannot initiate any handles; otherwise, this may lead to a >>>> deadlock. This limitation does not affect the iomap path, as it does not use >>>> the data=ordered mode at all. However, in the buffered_head path, online >>>> defragmentation (if this change works, it should be the last user) still uses >>>> the data=ordered mode. >>> >>> Right and my intention was to use reserved handle for the i_disksize update >>> similarly as we currently use reserved handle for unwritten extent >>> conversion after page writeback is done. >> >> IIUC, reserved handle only works for ext4_jbd2_inode_add_wait(). It doesn't >> work for ext4_jbd2_inode_add_write() because writebacks triggered by the >> journaling process cannot initiate any handles, including reserved handles. > > Yes, we cannot start any new handles (reserved or not) from writeback > happening from jbd2 thread. I didn't think about that case so good catch. > So we can either do this once we have delay map and get rid of data=ordered > mode altogether or, as you write below, we have to submit the tail folios > proactively during truncate up / append write - but I don't like this > option too much because workloads appending to file by small chunks (say a > few bytes) will get a large performance hit from this. > Yeah, so let's keep the buffered_head path as it is now, and only modify the iomap path to support the new post-EOF block zeroing solution for truncate up and append write as discussed. Cheers, Yi. >> So, I guess you're suggesting that within mext_move_extent(), we should >> proactively submit the blocks after swapping, and then call >> ext4_jbd2_inode_add_wait() to replace the existing >> ext4_jbd2_inode_add_write(). Is that correct? > > Honza