Re: [PATCH V12 04/12] famfs: Introduce inode_operations and super_operations

[John Groves <John@groves.net>]

On 26/08/05 10:12PM, Darrick J. Wong wrote:
> On Mon, Aug 03, 2026 at 02:28:56AM +0000, John Groves wrote:
> > From: John Groves <john@groves.net>
> > 
> > The famfs inode and super operations are generic other than
> > show_options, evict_inode and setattr (which prevents truncation..
> > 
> > This commit builds but is still too incomplete to run
> > 
> > Signed-off-by: John Groves <john@groves.net>
> > ---
> >  fs/famfs/famfs_inode.c    | 249 +++++++++++++++++++++++++++++++++++++-
> >  fs/famfs/famfs_internal.h |   6 +
> >  2 files changed, 252 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/famfs/famfs_inode.c b/fs/famfs/famfs_inode.c
> > index ad71e5e7a8e3..efc6b852eca0 100644
> > --- a/fs/famfs/famfs_inode.c
> > +++ b/fs/famfs/famfs_inode.c
> > @@ -29,6 +29,9 @@
> >  
> >  #define FAMFS_DEFAULT_MODE	0755
> >  
> > +static const struct inode_operations famfs_file_inode_operations;
> > +static const struct inode_operations famfs_dir_inode_operations;
> > +
> >  static struct inode *famfs_get_inode(
> >  			struct super_block *sb,
> >  			const struct inode *dir,
> > @@ -54,11 +57,11 @@ static struct inode *famfs_get_inode(
> >  		init_special_inode(inode, mode, dev);
> >  		break;
> >  	case S_IFREG:
> > -		inode->i_op = NULL /* famfs_file_inode_operations */;
> > +		inode->i_op = &famfs_file_inode_operations;
> >  		inode->i_fop = NULL /* &famfs_file_operations */;
> >  		break;
> >  	case S_IFDIR:
> > -		inode->i_op = NULL /* famfs_dir_inode_operations */;
> > +		inode->i_op = &famfs_dir_inode_operations;
> >  		inode->i_fop = &simple_dir_operations;
> >  
> >  		/* Directory inodes start off with i_nlink == 2 (for ".") */
> > @@ -72,6 +75,246 @@ static struct inode *famfs_get_inode(
> >  	return inode;
> >  }
> >  
> > +/***************************************************************************
> > + * famfs inode_operations
> > + */
> > +
> > +static int
> > +famfs_setattr(
> > +	struct mnt_idmap *idmap,
> > +	struct dentry *dentry,
> > +	struct iattr *iattr)
> > +{
> > +	struct inode *inode = d_inode(dentry);
> > +	struct famfs_fs_info *fsi = inode->i_sb->s_fs_info;
> > +
> > +	/* Resizing a famfs file (its size is pinned to the fmap) */
> > +	if ((iattr->ia_valid & ATTR_SIZE) &&
> > +	    !famfs_opt_enabled(fsi, FAMFS_OPT_TRUNCATE) &&
> 
> Does truncating the file down release the mapped memory?
> Can you truncate it up?  How does the famfs manager deal with this?

Truncate won't be enabled in any situation I can currently think of,
but it made sense to gate it with the opt_enabled mechanism in case
it makes sense at some point.

Space is not freed; It's still part of the daxdev, which is never
sparse.  The famfs metadata log is authoritative on allocations, and 
doesn't currently support delete, so the dax memory for a file is 
spoken for until the whole file system is killed.

There are cases where chmod/chown make sense, but the change is local
and ephemeral - not recorded to the metadata log.

> 
> > +	    iattr->ia_size != i_size_read(inode))
> > +		return -EPERM;
> > +	if ((iattr->ia_valid & ATTR_MODE) &&
> > +	    !famfs_opt_enabled(fsi, FAMFS_OPT_CHMOD))
> > +		return -EPERM;
> > +	if ((iattr->ia_valid & (ATTR_UID | ATTR_GID)) &&
> > +	    !famfs_opt_enabled(fsi, FAMFS_OPT_CHOWN))
> > +		return -EPERM;
> > +	if ((iattr->ia_valid & (ATTR_ATIME | ATTR_MTIME)) &&
> > +	    !famfs_opt_enabled(fsi, FAMFS_OPT_UTIMES))
> > +		return -EPERM;
> > +
> > +	return simple_setattr(idmap, dentry, iattr);
> > +}
> > +
> > +static const struct inode_operations famfs_file_inode_operations = {
> > +	/* All generic */
> > +	.setattr	   = famfs_setattr,
> > +	.getattr	   = simple_getattr,
> > +};
> > +
> > +/*
> > + * Internal inode creation helper, shared by ->create, ->mkdir, ->mknod and
> > + * ->symlink. Each of those callers is responsible for its own FAMFS_OPT_*
> > + * permission check before getting here.
> > + */
> > +static int
> > +famfs_mknod(struct mnt_idmap *idmap, struct inode *dir, struct dentry *dentry,
> > +	    umode_t mode, dev_t dev)
> > +{
> > +	struct famfs_fs_info *fsi = dir->i_sb->s_fs_info;
> > +	struct timespec64 tv;
> > +	struct inode *inode;
> > +
> > +	if (fsi->deverror)
> > +		return -ENODEV;
> > +
> > +	inode = famfs_get_inode(dir->i_sb, dir, mode, dev);
> > +	if (!inode)
> > +		return -ENOSPC;
> > +
> > +	d_make_persistent(dentry, inode);
> > +	tv = inode_set_ctime_current(inode);
> > +	inode_set_mtime_to_ts(inode, tv);
> > +	inode_set_atime_to_ts(inode, tv);
> > +
> > +	return 0;
> > +}
> > +
> > +static struct dentry *famfs_mkdir(struct mnt_idmap *idmap, struct inode *dir,
> > +		struct dentry *dentry, umode_t mode)
> > +{
> > +	struct famfs_fs_info *fsi = dir->i_sb->s_fs_info;
> > +	int rc;
> > +
> > +	if (fsi->deverror)
> > +		return ERR_PTR(-ENODEV);
> > +	if (!famfs_opt_enabled(fsi, FAMFS_OPT_MKDIR))
> > +		return ERR_PTR(-EPERM);
> > +
> > +	rc = famfs_mknod(&nop_mnt_idmap, dir, dentry, mode | S_IFDIR, 0);
> > +	if (rc)
> > +		return ERR_PTR(rc);
> > +
> > +	inc_nlink(dir);
> > +
> > +	return ERR_PTR(0);
> > +}
> > +
> > +static int famfs_create(struct mnt_idmap *idmap, struct inode *dir,
> > +			struct dentry *dentry, umode_t mode, bool excl)
> > +{
> > +	struct famfs_fs_info *fsi = dir->i_sb->s_fs_info;
> > +
> > +	if (fsi->deverror)
> > +		return -ENODEV;
> > +	if (!famfs_opt_enabled(fsi, FAMFS_OPT_CREATE))
> > +		return -EPERM;
> > +
> > +	return famfs_mknod(&nop_mnt_idmap, dir, dentry, mode | S_IFREG, 0);
> 
> Is the model here that you creat() a file and then the famfs server has
> to go find it some cxl memory?  I was kinda under the impression that
> you'd get the famfs software to map some memory to a name, and then the
> famfs server on each node would create it and upload the mapping, and
> now the cxlmem-backed file can be mmaped from multiple nodes?
> 
> But maybe this is less of a cluster filesystem than I assumed it was.
> 
> --D

Not quite. The memory is allocated when a file is committed to the
metadata log, before a file is ever creat'd. When the log is played, 
initially empty file instances get created (by the famfs lib in user
space) and then the fmaps get passed in via FAMFS_IOC_MAP_CREATE 
(after which files are usable). (the word "file" is admittedly 
overloaded here; hope it makes sense.)

The cluster aspect is unusual if not unique. Only one node (the master) 
can write the MD log, meaning only that node can create files (by which 
I mean commit file_create log entries). Other nodes can only play the 
log, which guarantees they see files that point the the same memory 
cluster-wide.

Although file allocation is immutable until you kill the superblocks
and start over, data can be mutable from any node you like. This is
definitely unusual.

The MD log is append-only, and does not support mutations to allocation
(truncate/append/delete), which solves the cluster consistency problem
around which files point where. The worst structural inconsistency
that's possible, if some nodes are behind on playing the log, is that
those nodes don't see the newest files.

Thank you!
John

<snip>