On Thu, 29 Feb 2024 at 07:52, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > I'm not virtiofs expert, but I don't think that you are wrong about this. > IIUC, virtiofsd could map arbitrary memory region to any fuse file mmaped > by virtiofs client. > > So what are the gaps between virtiofs and famfs that justify a new filesystem > driver and new userspace API? Let me try to fill in some gaps. I've looked at the famfs driver (even tried to set it up in a VM, but got stuck with the EFI stuff). - famfs has an extent list per file that indicates how each page within the file should be mapped onto the dax device, IOW it has the following mapping: [famfs file, offset] -> [offset, length] - fuse can currently map a fuse file onto a backing file: [fuse file] -> [backing file] The interface for the latter is backing_id = ioctl(dev_fuse_fd, FUSE_DEV_IOC_BACKING_OPEN, backing_map); ... fuse_open_out.flags |= FOPEN_PASSTHROUGH; fuse_open_out.backing_id = backing_id; This looks suitable for doing the famfs file - > dax device mapping as well. I wouldn't extend the ioctl with extent information, since famfs can just use FUSE_DEV_IOC_BACKING_OPEN once to register the dax device. The flags field could be used to tell the kernel to treat this fd as a dax device instead of a a regular file. Letter, when the file is opened the extent list could be sent in the open reply together with the backing id. The fuse_ext_header mechanism seems suitable for this. And I think that's it as far as API's are concerned. Note: this is already more generic than the current famfs prototype, since multiple dax devices could be used as backing for famfs files, with the constraint that a single file can only map data from a single dax device. As for implementing dax passthrough, I think that needs a separate source file, the one used by virtiofs (fs/fuse/dax.c) does not appear to have many commonalities with this one. That could be renamed to virtiofs_dax.c as it's pretty much virtiofs specific, AFAICT. Comments? Am I missing something significant? Thanks, Miklos
