From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 E51833AA9D4 for ; Sun, 11 Oct 2026 05:29:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791696588; cv=none; b=SO7+Lc3Zem6/mPiQmp0AabDLANWw6mYYx9JHdzy3pNY12mELUThupeluvBQhlXVmG4VcaA35pyDitcti9GLUKVO+YgtTD8CD6FtW7Ym/ljyAA/cDWJoP57VqpotjkKEyUmxSxTADw24IlRP6x1otq01BIHIjYEaxL62koX0KojU= 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=eqefMXFC; arc=none smtp.client-ip=209.85.128.50 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="eqefMXFC" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4a061a13884so8019695e9.3 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=vger.kernel.org; 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=eqefMXFCtMdjqzxlckHAdKhdWg45OVbq12RRfTeUnpr5REQeBjRlA4pvRF/8tX2SrU DOxrr52H3C0AgyMCvq5wtF1r/IYYnEersFGO9EFi3Iu2k1HLsXzNf4IT+bWUR2+wVoJj xl41LRWS6re51wj+N3vj+nJQOwbAQxAPdTARg= 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=gJpweacASTofeFUvsmDr0thZrBgftGOt7wbKP/49zO/SCCpt203ZmPjeIVcw14f/F9 mbWyiymtI25rXD+tgZjbav7KxCkyxG7eQIifNOgA2eamkKcKSkCAY7YkQCr01L5VRpVQ BLbGuoQMgE1lmJsxyEpLQtdaw00j4kT8mE92T4bwbFm+spBhgsnj9WqJStA5lwjXnYS+ POtvOK21h6aHN6DAbaX1BZtvjWipAJ2SLZHUmENK6/8nh+5yDle8ub3ucjS6gRyftWko 1uAq9OTtq2XgOwrWdDhX9oMr7THB3OrTUJKcmqiDMqxgkdwdLvhNKiAAadpO8rKivlEK KnZg== X-Forwarded-Encrypted: i=1; AKwUvByjc4MUyNIGs5hWUcank64pAUbRagHllOUpsMQg136lzDyb0HH8mCxizuPgtMX+NFLwxN8NJOTk1hhryk0=@vger.kernel.org X-Gm-Message-State: AFq9FYKQ41G0eL7QW3CXX5INjn27MsiO84vFVsb33taeFyOXBpsHukt0 24n+SibPH1dp5+ib+m3lVEJDbNK2auaPQbwGCZz8Lvf5lnprrN73K78HeNmDa7CG3w== X-Gm-Gg: AYBFou27+7bU/Cz6WRHyiiNrF3vpjY0Nf61OW7QJhaUoZ36JRKIMU5sMA8mqA94WWZF yCiUsdiKXohQjP7Cq9dDyqw5wdBpkWNAvMVvXohMQxbYKHOkntaBSNyJRhE4Ur1x2mrhvwOpAra 18RXhY4DoRlq6IJ7YelKdEtJxEUIeMDmJ4+vV48+hatfLqDK68aEmnII5viNGzHBg4I3YuzZhs/ s+lTcNVRBuTlyKWKI6wkibuHEIeR8+Mnj72bXJrUHxbJqsrl0fGmR9FRkm4RIgmCUUaurhrzyCM RFW+46U0T3IKYmv2rBt7Bybnqenb32r4h5+0lJ3t41VAyqwYmzayr1ZIS0gR/bAw+1/wREpgZ99 X9ScyKvf736apCAinJtcIoekx9b/P8LdkuS384JEK8f2sA9MWMOH/e/HWT0Kgxo4NKGKrLUU+nF ljKkmYd000rL6vJ/tZjQPS4VjGmyj6E71jJ9a9udqAYqNGRdWjxTTzJKlKbuHmqHw1Y8ZLiearU INi+KgRd1OrX/kdX36YFfgWjbQ6oreHvcolkFjjMk9OXI898iDuNr+aXh6F8Eh3d/42z1L1nKVl t0/wsHyoMUEIchR0IE03w4U9rR4s6wU= 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: linux-kernel@vger.kernel.org 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