From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80882353346; Tue, 19 Aug 2025 22:17:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755641832; cv=none; b=pLAcEqNlwo/Zlcgiwu3WfT4UW80oQU7Y59oacbxgF/s05G111/EzgLalkfJKw2/QjYFZkm3snoXcqRrX8TnCXa3Z1Eau+P1eIw4SRSwBd0VRmxp7qBJ+K0Klqoraa2wydfe02oflVlCn0MvXRh3ClOanTjQ/GkHqLgtq1h3GtzQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755641832; c=relaxed/simple; bh=hxKNVzwm+0xg7CiDywgUBg6GHS2F2cVK6OSq8JAgv0Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r3UQH4m6tPrbVNpVUUiiGgiqdZl1ZmLy+rVLbDlI4fpjQT67wGvSo7xFwDSxImPPratnoj9JpG35BEI7wmsHB2ciPFXUPTd9VMoIn72x4+hqURcF80wbtL6XMRf93FgytN5LMsDhxUCKxj95haTnX+41qJJOrFWTeV5kAEyHdT0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kNtinz25; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kNtinz25" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03B56C4CEF1; Tue, 19 Aug 2025 22:17:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755641832; bh=hxKNVzwm+0xg7CiDywgUBg6GHS2F2cVK6OSq8JAgv0Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kNtinz25M4hJVHOFhujRaR+8bFeXgOCDh0RMbM1fycUNrfZjjqtRV/cB6J6rdxI1A E1Jizr/OpdHnhY5k4pUbLJ0a/NVIcqkMxEKaTHnIZZkQhihgifev0doEbryGx8cC8G Vr5jembNJoMNp4/O6XjeyQDPzThU6ZaN941caMvVXjBjmKLcg/ebuhQ8h1RrxdXRtF fKT4UxSrtKp2ZJg/KlrMg/N+kDqIZmCrNdguCrcOTiftAk3EIOvebj8ZC/Efj7byps LVmAHWZ9eucxCxTyt0iJdxc081s8sY9vMJvptiaeegi2WSn/NoozEA/OwJEkNRHcGl MhalCSkLvMnOw== Date: Tue, 19 Aug 2025 15:17:11 -0700 From: "Darrick J. Wong" To: John Groves Cc: Miklos Szeredi , Dan Williams , Miklos Szeredi , Bernd Schubert , John Groves , Jonathan Corbet , Vishal Verma , Dave Jiang , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Randy Dunlap , Jeff Layton , Kent Overstreet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org, Amir Goldstein , Jonathan Cameron , Stefan Hajnoczi , Joanne Koong , Josef Bacik , Aravind Ramesh , Ajay Joshi Subject: Re: [RFC V2 12/18] famfs_fuse: Plumb the GET_FMAP message/response Message-ID: <20250819221711.GF7942@frogsfrogsfrogs> References: <20250703185032.46568-1-john@groves.net> <20250703185032.46568-13-john@groves.net> <20250814180512.GV7942@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Aug 16, 2025 at 10:00:23AM -0500, John Groves wrote: > On 25/08/14 11:05AM, Darrick J. Wong wrote: > > > It's possible that famfs could use the mapping upsertion notification to > > upload mappings into the kernel. As far as I can tell, fuse servers can > > send notifications even when they're in the middle of handling a fuse > > request, so the famfs daemon's ->open function could upload mappings > > before completing the open operation. > > > > Famfs dax mappings don't change (and might or might not ever change). > Plus, famfs is exposing memory, so it must run at memory speed - which > is why it needs to cache the entire fmap for any active file. That way > mapping faults happen at lookup-in-fmap speed (which is order 1 for > interleaved fmaps, and order-small-n for non-interleaved. > > I wouldn't rule out ever using upsert, but probably not before we > integrate famfs with PNFS, or some other major generalizing event. Hrm? No, you'd just make the famfs ->open function upsert all the relevant mappings. Since the mappings are all fully written and (presumably) within EOF, they'll stay in the cache forever and you never have to upload them ever again. Though it's probably smarter to wait for the first ->iomap_begin to do the upserting because you wouldn't want waste kernel memory until something actually wants to do IO to the file. --D > Thanks, > John > > > >