From nobody Mon Feb 9 23:50:11 2026 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (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 BD00F209F43 for ; Sun, 4 Jan 2026 06:51:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767509485; cv=none; b=CPkZHy03VtD8BO9tYfBxE6wLwqpMlIz1zQF4o+DtWaOFawo9GoTgXWNnY848MpfWX7Y1W8txyGcxf0WoWPzSUDxSQfEMGyVhnXFK5uM3AfVGK8ZoPOOnK8h9Lcviovqb2pZrEZiAKWvVRJoV98uyPxI4BJAFpNenTkubYukgrfw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767509485; c=relaxed/simple; bh=6zrvH/Y6xj4ImMc7hbH57hysfldTJmwwfrXUGUhRLhw=; h=Mime-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=KCf1vL7Rh3DldYj+glJCuLhVpbTNF36F9YZbaNMQjKaU6sSXkIx6lm5vpnjDs85DuXJJke1tDuuBnB03pgQjXkWL/I71PMitqpjwdzsr5WhX4latGXpWGBO3jbvDUg5/KwPdqQ8rQxE9+2pwRDEKM8z5vZ/4YMVH7Uu/OfCPd9g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=OjPYTMch; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="OjPYTMch" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2a1022dda33so105293435ad.2 for ; Sat, 03 Jan 2026 22:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1767509483; x=1768114283; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6zrvH/Y6xj4ImMc7hbH57hysfldTJmwwfrXUGUhRLhw=; b=OjPYTMchVEL33uYhFsibtk4+fbIi40YvRzNPzcPsbR0/2JTnnYHeG0EmlWFpCEaVlq 4FsIp0ETk9OUvDmnQ2syOaG77glJIMzCnuInun8kbs/fERo0GRX2XOXA5DEKxGooZAqD ybjoDapOBRXOs14Ch9DWD30wdxV4RTkDjaMK+eSruvHwQYL1TemrDPqq46ajl49xGfT0 TnCPwEjfjw0ZNjiLFd6g18K71CWiJEiB5jLEsMbUU3x3k2LjrqbfkfMQEZB3nQT1FgDI w3RHafPorcsNLxnH16+mmsDjybMFC3O2rkTwPtbZLJ2R3HPuErq/2/Yvnit5mSJ88ULp TpLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767509483; x=1768114283; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6zrvH/Y6xj4ImMc7hbH57hysfldTJmwwfrXUGUhRLhw=; b=pJJc5pLtm1DTwNqsnJ1oT7fkK3J6hKuyYTQmqncUEd4G2MHd7cBcPYVv+LYGbEXcJj wkwGnq7BRaA3Y7nw53lwm1kudjrtiKqYVeFsrt0vGCKtYWiWqBkRZT5KMQhdC8NQFG2T JPoreAfJmUr2Q9WO/iUOF3u6f/o4Wm5hunXNGVUCbo9z8qBCwYwSemrN+PHIYxGwWoek FjTjm2JRFUgEGvOQV+YhABynD7yJw7S30yJg+FJNhrlQnJocumskFl0/zkzR0u8AZ7Im /O88M8/zGamrQ7f16sqeVdXPsrEZfDR8TuvMxh3gsPcLbEAi+GcnAACHzy+WO9xumiQR dh8A== X-Forwarded-Encrypted: i=1; AJvYcCU9xTfbHpx0Ju/xUlvbzfD22/1XkqccEgIFDwr2OPqWeKWdspu0hkIKY7Lv5QqASlOrJZmkpsk33SJzgO8=@vger.kernel.org X-Gm-Message-State: AOJu0YywFb5iJR13W51isNLhZHVRrskWwBBuzYu0ELhanmdOAsQCLDbO c1YXWo64bx1xKJ4POVHPf1BoHl7Qt0RFtVbZH2G4TcfEBMSfTVYxX57wCQqAzCWCl8uVGuHXHXu rkl/OgjYJZ42zNU4r6HWzFHTPadEnFbXyrEupmBjGmwdv94IHeJZ6 X-Gm-Gg: AY/fxX6OVeGivJow3VvHYctEgm1qv6DMEoItyroK5cOhJVqnK1VSLykSgyUF+q/mf7V zV1YYMrzKrRfapCUqHcDZU0GVpWkyKPHqh4NKQtyFElCR2vDDllmmG+EA5yZJiV9MzM6tF8tU7b wgMvvtFNnniV9EooiNow5QPXdwRBykDlWJ2vU4gsgFdJCuGsP1QRS6h4eTYgvCCOTtHNTL5LVPD OdI+TOhGc5GiBCKDTJL2CkAdKQHyFoaVLS7iOJ2F+4CXkbFoBfasSXDN/RwRngNu61BCsw= X-Google-Smtp-Source: AGHT+IHEAp/0Uc42kWijpM2HjcTQxPtxvKnhqNUvcFoStiKxYNNrELPPWVIjU/gLXl2Nucc8SX4ABd99S6P+454wyo0= X-Received: by 2002:a17:903:3b8b:b0:2a0:b461:c883 with SMTP id d9443c01a7336-2a2f2a354ebmr444934985ad.45.1767509483005; Sat, 03 Jan 2026 22:51:23 -0800 (PST) Received: from 44278815321 named unknown by gmailapi.google.com with HTTPREST; Sun, 4 Jan 2026 06:51:22 +0000 Received: from 44278815321 named unknown by gmailapi.google.com with HTTPREST; Sun, 4 Jan 2026 06:51:22 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 From: Zhang Tianci Date: Sun, 4 Jan 2026 06:51:22 +0000 X-Gm-Features: AQt7F2rLFSKIBx_vo7nV2oTn4tgI-gsnDi4JWnKTHuLFxCFiIik9i1XzBTLQYIc Message-ID: Subject: [QUESTION] fuse: why invalidate all page cache in truncate() To: miklos Cc: linux-fsdevel , linux-kernel , =?UTF-8?B?6LCi5rC45ZCJ?= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi all, We have recently encountered a case where aria2c adopts the following IO pattern when downloading files(We enabled writeback_cache option): It allocates file space via fallocate. If fallocate is not supported, it will circularly write 256KB of zero-filled data to the file until it rea= ches an enough size, and then truncate the file to the desired size. Subsequentl= y, it fills non-zero data into the file through random writes. This causes aria2c to run extremely slowly, which does not meet our expectations, because we have enabled writeback_cache, random writes should not be this s= low. After investigation, I found that a readpage operation is performed in every write_begin callback. This is quite odd, as the file was just fully filled = with zeros via write operations; the file's page cache should all be uptodate, so there is no need for a readpage. Upon further analysis, I discovered tha= t the root cause is that truncate has invalidated all the page cache. I would like to know why the invalidation is performed. After checking the = code commit history, I found that this has been the implementation since FUSE ad= ded support for the writeback cache mode. Therefore, I can only seek help from the community: What were the considerations behind this implementation, and can it be removed? --- a/fs/fuse/dir.c +++ b/fs/fuse/dir.c @@ -2279,7 +2279,6 @@ int fuse_do_setattr(struct mnt_idmap *idmap, struct dentry *dentry, =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 if ((is_truncate || !is_wb) && =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 S_ISREG(inode->i_mode) && ol= dsize !=3D outarg.attr.size) { =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 truncate_pagec= ache(inode, outarg.attr.size); - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 invalidate_inode_pages2(= mapping); =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 } =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 clear_bit(FUSE_I_SIZE_UNSTABLE, &fi->state= ); Thanks, Tianci