From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 F2B323C3C0C for ; Sun, 11 Oct 2026 05:29:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791696588; cv=none; b=uQZqyffAqir+115nkXTLMDKTuyq7C4kz0srGFZqpRGe/n8t9uknHxsxTD6Ssx9cc0P0O3qfdQ8TpIFH6QKYftDrPZYuQB+zKWcxn6+RqhEM3M1a07h4yIgXhmcXqAJfxrjrrYEYIAzZNA3IIIQsMKuDYl/SCy0AoTc33jmF0hxk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791696588; c=relaxed/simple; bh=sIbRso6W6WqLNYE6yLPCDLJ+kUhhHofo7p2mjFJFouk=; h=From:To:Cc:Subject:Message-ID:In-Reply-To:References:Date: MIME-Version:Content-Type; b=PfhlSu0wRdB81Es9lqYA+PyzFY8lnnsoOa7sJdQLYv8Rz/R6ZfFWcvfel08LpDVHxsIcSaKiS5ut309atSSzOEYxEoxfvazMIDGpkwzH2UT28+/4BJgOlrv/uOMIFk1+Nq7mcAvL3kexKz8IwnmyqLx5VyVbA3MoysRgKzHActU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=innovatrics.com; spf=pass smtp.mailfrom=innovatrics.com; dkim=pass (1024-bit key) header.d=innovatrics.com header.i=@innovatrics.com header.b=bWs6mx5m; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=innovatrics.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=innovatrics.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=innovatrics.com header.i=@innovatrics.com header.b="bWs6mx5m" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4a01933b584so8364655e9.0 for ; Sat, 10 Oct 2026 22:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=innovatrics.com; s=google; t=1791696585; x=1792301385; darn=lists.linux.dev; h=content-type:mime-version:date:references:in-reply-to:message-id :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EwJQAcrSA8vm2/QDhj4tfogkpVMYET7O/tmaR0Uw6Xg=; b=bWs6mx5mn612s8rIAAaKenRTjP2YKqiMABBEhR4YFb58f0mFnCKCRQaKI76mWupMmo yPFZGsifFzZyQF/JVjLPqKUAiM4mPFV+d8U9DqGXpPemFEJHi/Q+tojmVNCU+orsAG39 Vr2et82o3FFU9NHc0eD+1+6vFF1rafR2LKc6I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791696585; x=1792301385; h=content-type:mime-version:date:references:in-reply-to:message-id :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=EwJQAcrSA8vm2/QDhj4tfogkpVMYET7O/tmaR0Uw6Xg=; b=jCZ1X+NUkLV7oODFWNduURqbH9qaA1c0aVN1ybr8FCgMKAZZkaFg/7Q1OPtZ2lOBUX rtQ3or21vGISUPbXIJdxXMD7vXR6rxIbzeefrPl4gZDB3h8830VGL4IQD6PHIXZQN4nV NeLq35/vNsEwOCOWqMsGB+qgMCw76VNSerYLUKyjG1EHwr3hjiSaZ+dKLW6xhtlpg0oX QYveYeHkgveUWEOY3FwZgIdIXDsf603EDPPFUg1mKuwyb7kh0QugYLyEkk9IHFxxTFUo Fmg7DFpx2aPBPwRo4MoN1DbzbmXBCVWIGOZhGCKmnJLefN4O4Skxnjg4YkiJAHUJvv1r /6pw== X-Forwarded-Encrypted: i=1; AKwUvBxbROoiP7qbAK5XxawaPW4kbc4ypNeDIQSZLGjrpLetNBKigQPk15PcswfNA0ZafIbc6SJMVQ==@lists.linux.dev X-Gm-Message-State: AFq9FYKy1bhzS9wTguO7cIGQ52ezjqbYtCrn4oYZJWxExIyHoltGpLeE 6zMoF6KQ1rLFhJlhaztcqacVlT0tSKKL3H47tuGpj7Trw73QapQARcsktvDPoYLCyw== X-Gm-Gg: AYBFou07JG3sPbBgy0irwtXBDkwXcXpmhl1XYnJXMnE9ewVNKTJCYvdc47rWRJK5WG6 5UKIA6+DmD9+326AWpuXYcAVpMmScaTsilL5VfUiULIFf/btfZ6EZNMjh0ry8JztSBcrnjYM95j W7Sl6DTMq8XWheJCgaBXQwn/nsSoeTd5G9khBJhRZIJ67lwetv8JIVzXv03MZVtNJRAkkPxcUTL GmnmIPa3USkiYpRhBFdpH9W44fn66w2ZwS+rGq6f6iEdSQqYy/sLTgrWkjoi8QiHXUOiN0OLDzR 4gUztz6MYDFmOC2OSop0MSR+nj6MqtMOZfu2jUgLhuZ/FfugbcaJlgKueKdVLsrvb7lmMEQD8ti YCUnJ73DxjqQAQlLs3mE6ZkGz7jHUsrZ1HGZ5FgGs2O0baesZ2283rtS6K6abY3cvVcOBLPB0c9 VRPJgiNavNz3bAH2fbbe+Mxqwb3bDCNYjp1yXYXrRthLpjGjwm/VXP9EfyAN0l5LNKMxYqd6To0 Gmk8ujOh8YZtewqk+sPcqG0s2PEhiiUVvVLICfXyb5tzK3WAWBLCXKPZtU375ew/wYgn0R1x39o TByu0z9YMEMI21KTAO5Bh/uj5iFAlJE= X-Received: by 2002:a05:600c:e558:20b0:4a1:946c:953f with SMTP id 5b1f17b1804b1-4a1946c9744mr30278845e9.20.1791696585122; Sat, 10 Oct 2026 22:29:45 -0700 (PDT) Received: from [10.11.72.5] (bip-static-148.213-81-147.telecom.sk. [213.81.147.148]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a193f2c992sm107606015e9.5.2026.10.10.22.29.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 10 Oct 2026 22:29:44 -0700 (PDT) From: Petr Chmelar To: David Howells Cc: Christian Brauner , Paulo Alcantara , Matthew Wilcox , Namjae Jeon , Marc Dionne , Stefan Metzmacher , Eric Van Hensbergen , Dominique Martinet , Ilya Dryomov , netfs@lists.linux.dev, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v12 4/5] cachefiles: Don't rely on backing fs storage map for most use cases Message-ID: <20261011.cachefiles-partial-zeros.pchmelar@innovatrics.com> In-Reply-To: <20260910220242.2165023-5-dhowells@redhat.com> References: <20260910220242.2165023-1-dhowells@redhat.com> <20260910220242.2165023-5-dhowells@redhat.com> Date: Sun, 11 Oct 2026 05:29:43 +0000 Precedence: bulk X-Mailing-List: netfs@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Hi David, With this patch, reading a file whose cache object is only partly filled returns wrong data, mostly whole 64 KiB blocks of zeros. A second full read returns the same wrong blocks. It reproduces over NFS and 9p on vfs-7.4.netfs (9f8b64f66). Over 9p it bisects to this patch, 13e340e397 in that branch; over NFS its parent is clean and the branch tip is not. #regzbot introduced: 13e340e397 Reproducer: random 64 KiB reads covering half of a 256 MiB file of random data, then a full read after dropping the page cache, compared with the original per 64 KiB block: fio --name=half --filename=/mnt/part.bin --rw=randread --bs=64k \ --ioengine=psync --fadvise_hint=random --size=256m --io_size=128m \ --randrepeat=1 sync; echo 3 > /proc/sys/vm/drop_caches cmp /mnt/part.bin /path/to/original Setup: QEMU 8.2.2 (TCG, 4 vCPUs), cache on a fresh XFS on a loop device (2 GiB for 9p, 4 GiB for NFS), cachefilesd 0.10.10 with brun 10%, bcull 7%, bstop 3%, fio 3.36. Mounts: NFS: NFSv4.2 loopback export of a tmpfs, vers=4.2,fsc,actimeo=1 9p: trans=virtio,version=9p2000.L,cache=fscache,msize=1048576 Wrong 64 KiB blocks out of 4096, first full read / second full read: kernel mount wrong all zeros v7.3-rc6 9p 0 / 0 0 e0aa90eb8c 9p 0 / 0 0 98e0cd700d (parent) 9p 0 / 0 0 98e0cd700d (parent) NFS 0 / 0 0 13e340e397 (this) 9p 936 / 936 825 8097a263bd (merge) 9p 936 / 936 825 9f8b64f66 9p 936 / 936 825 9f8b64f66 NFS 817 / 817 817 9f8b64f66 9p loose 0 / 0 0 "9p loose" is the 9p mount with cache=loose, without fscache. On 9f8b64f66 over 9p, three runs gave the same counts and the same first wrong blocks. The first wrong blocks are 10, 13, 15, 24, 26 and 27 over 9p, and 50, 51, 53, 54, 55 and 56 over NFS. Two more observations, in case they help: - Over 9p, after the random fill and both full reads, the backing object has 451 extents with this patch and 28 on v7.3-rc6 (37 on 98e0cd700d). - Over NFS on 9f8b64f66, the fscache counters after the fill and both full reads are IO rd=371 wr=2189. I haven't traced whether the zeros come from reads over holes in the backing file or from what was written to it. Over NFS, a server-side rewrite of the file (invalidation) and a shrink and regrow through the mount both read back correctly on 9f8b64f66 and 98e0cd700d. I found this while testing a workaround for slow reads from fragmented cache objects, which I describe in a reply to the cover letter: https://lore.kernel.org/r/20261011.cachefiles-seek-hole-walk.pchmelar@innovatrics.com It reproduces without that workaround. The reproducer and the bisection were done with LLM assistance. Thanks, Petr