On 24/04/29 07:08PM, Kent Overstreet wrote: > On Mon, Apr 29, 2024 at 07:32:55PM +0100, Matthew Wilcox wrote: > > On Mon, Apr 29, 2024 at 12:04:16PM -0500, John Groves wrote: > > > This patch set introduces famfs[1] - a special-purpose fs-dax file system > > > for sharable disaggregated or fabric-attached memory (FAM). Famfs is not > > > CXL-specific in anyway way. > > > > > > * Famfs creates a simple access method for storing and sharing data in > > > sharable memory. The memory is exposed and accessed as memory-mappable > > > dax files. > > > * Famfs supports multiple hosts mounting the same file system from the > > > same memory (something existing fs-dax file systems don't do). > > > > Yes, but we do already have two filesystems that support shared storage, > > and are rather more advanced than famfs -- GFS2 and OCFS2. What are > > the pros and cons of improving either of those to support DAX rather > > than starting again with a new filesystem? > > I could see a shared memory filesystem as being a completely different > beast than a shared block storage filesystem - and I've never heard > anyone talking about gfs2 or ocfs2 as codebases we particularly liked. Thanks for your attention on famfs, Kent. I think of it as a completely different beast. See my reply to Willy re: famfs being more of a memory allocator with the benefit of allocations being accessible (and memory-mappable) as files. > > This looks like it might not even be persistent? Does it survive a > reboot? If not, that means it'll be much smaller than a conventional > filesystem. Right; cxl memory *can* be persistent, but most of the future products I'm aware of will not be persistent. Those of us who work at memory companies have been educated in recent years as to the value (or lack thereof) of persistence (see 3DX / Optane). But since shared memory is probably on a separate power domain from a server, it is likely to persist across reboots. But it still ain't storage. > > But yeah, a bit more on where this is headed would be nice. The famfs user space repo has some good documentation as to the on- media structure of famfs. Scroll down on [1] (the documentation from the famfs user space repo). There is quite a bit of info in the docs from that repo. The other docs from the cover letter are also useful... > > Another concern is that every filesystem tends to be another huge > monolithic codebase without a lot of code sharing between them - how > much are we going to be adding in the end? A fair concern. Famfs is kinda fuse-like, in that the metadata handling is mostly in user space. Famfs is currently <1 KLOC of code in the kernel. That may grow, but it's not clear that there is a risk of "huge monolithic". But it's something we should consider - and I'll be at LSFMM and happy to engage about this. > > Can we start looking for more code sharing, more library code to factor > out? > > Some description of the internal data structures would really help here. [1] https://github.com/cxl-micron-reskit/famfs/blob/master/README.md Best regards, John
