From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) (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 3511925B2F4; Tue, 14 Apr 2026 13:41:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776174120; cv=none; b=UVnLV9J/E8EkwWjp65Tivxi5TGLjxA6GJGybCdhc+HNScMNAYjQpUCY0EsLgd88mkUtr4rn3k8K29b4RGvcyo3yNI+5wpdkgVJCmyebgDn8LVswhSscav2tgOwecQn5rIVAoVEyHRvIHPK0ZLERLyARsHF1aK4VOPpfDU68TFtE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776174120; c=relaxed/simple; bh=RHpptF+atO/Rhx/afsgSrALZFOyszUomvjg2Qi2fN+0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ViQFIUKmbC9AXvh8+IkzM9zHYGivjAsadgmW+80Be64zD9++7U/rNc/+77O51UEwgAr63MpsCBrXDq1EFe1odouty1mdmutNTJAp1F2LhIyD6SNJeF/qpnx1F/fuWkl39EU/ybKuCxhWbHJSz/6YUGECWbCurHAlhNRNZlolzMQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=groves.net; spf=pass smtp.mailfrom=groves.net; arc=none smtp.client-ip=216.40.44.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=groves.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=groves.net Received: from omf06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 730F9B9CAA; Tue, 14 Apr 2026 13:41:54 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: john@groves.net) by omf06.hostedemail.com (Postfix) with ESMTPA id 834B820011; Tue, 14 Apr 2026 13:41:43 +0000 (UTC) Date: Tue, 14 Apr 2026 08:41:42 -0500 From: John Groves To: Miklos Szeredi Cc: Joanne Koong , Bernd Schubert , John Groves , Dan Williams , Bernd Schubert , Alison Schofield , John Groves , Jonathan Corbet , Shuah Khan , Vishal Verma , Dave Jiang , Matthew Wilcox , Jan Kara , Alexander Viro , David Hildenbrand , Christian Brauner , "Darrick J . Wong" , Randy Dunlap , Jeff Layton , Amir Goldstein , Jonathan Cameron , Stefan Hajnoczi , Josef Bacik , Bagas Sanjaya , Chen Linxuan , James Morse , Fuad Tabba , Sean Christopherson , Shivank Garg , Ackerley Tng , Gregory Price , Aravind Ramesh , Ajay Joshi , "venkataravis@micron.com" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "nvdimm@lists.linux.dev" , "linux-cxl@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , djbw@kernel.org Subject: Re: [PATCH V10 00/10] famfs: port into fuse Message-ID: References: <20260331123702.35052-1-john@jagalactic.com> <0100019d43e5f632-f5862a3e-361c-4b54-a9a6-96c242a8f17a-000000@email.amazonses.com> <38744253-efa3-41c5-a491-b177a4a4c835@bsbernd.com> 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=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 834B820011 X-Stat-Signature: osob67n6eeczx8asmfbkzmfutkb4digx X-Rspamd-Server: rspamout03 X-Session-Marker: 6A6F686E4067726F7665732E6E6574 X-Session-ID: U2FsdGVkX1+SVXLkp0hdoyxt/nYLVnuiJzgDSoB6drE= X-HE-Tag: 1776174103-201279 X-HE-Meta: U2FsdGVkX1+o+SRZZyzbR/R8njSUkeQWUwyoCzq04hU35apA7vVzWjjcQZgAMC9iX79jqY5MWMkP/7pWmCK235zT8/aTsAsxYhxiuuOis90g52GWRjdVEgaJBEp9UNimWGcgLUYYf6q9bHFUP+zOcgei1JxxtJhIQPLOUUKv1fwweYnXqZo4S4DUdr5ll+JmdYAv/ic1UFSt8hMutBQLUuvY55NXZrJCZmjY0ehh+oC8FM7aRMt1KdWwS0XdOI3Isx2fv8ky16IEl496GV+NavoLMO6BLWPyHunqtIojvdpcTGM0qcW50KufiA7H/0pWXdI1ozUIbRKaisJT7LybGrmMWmGeL8mK On 26/04/14 03:19PM, Miklos Szeredi wrote: > On Fri, 10 Apr 2026 at 21:44, Joanne Koong wrote: > > > Overall, my intention with bringing this up is just to make sure we're > > at least aware of this alternative before anything is merged and > > permanent. If Miklos and you think we should land this series, then > > I'm on board with that. > > TBH, I'd prefer not to add the famfs specific mapping interface if not > absolutely necessary. This was the main sticking point originally, > but there seemed to be no better alternative. > > However with the bpf approach this would be gone, which is great. > > So let us please at least have a try at this. I'm not into bpf yet, > but willing to learn. > > Thanks, > Miklos Thanks for responding... My short response: Noooooooooo!!!!!! I very strongly object to making this a prerequisite to merging. This is an untested idea that will certainly delay us by at least a couple of merge windows when products are shipping now, and the existing approach has been in circulation for a long time. It is TOO LATE!!!!!! Famfs is not a science project, it's enablement for actual products and early versions are available now!!! That doesn't mean we couldn't convert later IF THERE ARE NO HIDDEN PROBLEMS. What are the risks of converting to BPF? - I don't know how to do it - so it'll be slow (kinda like my fuse learning curve cost about a year because this is not that similar to anything else that was already in fuse. - Those of us who are involved don't fully understand either the security or performance implications of this. It - Famfs is enabling access to memory and mapping fault handling must be at "memory speed". We know that BPF walks some data structures when a program executes. That exposes us to additional serialized L3 cache misses each time we service a mapping fault (any TLB & page table miss). This should be studied side-by-side with the existing approach under multiple loads before being adopted for production. - This has never been done in production, and we're throwing it in the way of a project that has been soaking for years and needs to support early shipments of products. If this is the only path, I'd like to revive famfs as a standalone file system. I'm still maintaining that and it's still in use. Please reconsider Miklos. To use an American football metaphor, this moves the goal posts by a mile, and that's not reasonable!!! Thanks, John