On 25/04/20 08:33PM, John Groves wrote: > Subject: famfs: port into fuse > > <snip> I'm planning to apply the review comments and send v2 of this patch series soon - hopefully next week. I asked a couple of specific questions for Miklos and Amir at [1] that I hope they will answer in the next few days. Do you object to zeroing fuse_inodes when they're allocated, and do I really need an xchg() to set the fi->famfs_meta pointer during fuse_alloc_inode()? cmpxchg would be good for avoiding stepping on an "already set" pointer, but not useful if fi->famfs_meta has random contents (which it does when allocated). I plan to move the GET_FMAP message to OPEN time rather than LOOKUP - unless that leads to problems that I don't currently foresee. The GET_FMAP response will also get a variable-sized payload. Darrick and I have met and discussed commonality between our use cases, and the only thing from famfs that he will be able to directly use is the GET_FMAP message/response - but likely with a different response payload. The file operations in famfs.c are not applicable for Darrick, as they only handle mapping file offsets to devdax offsets (i.e. fs-dax over devdax). Darrick is primarily exploring adapting block-backed file systems to use fuse. These are conventional page-cache-backed files that will primarily be read and written between blockdev and page cache. (Darrick, correct me if I got anything important wrong there.) In prep for Darrick, I'll add an offset and length to the GET_FMAP message, to specify what range of the file map is being requested. I'll also add a new "first header" struct in the GET_FMAP response that can accommodate additional fmap types, and will specify the file size as well as the offset and length of the fmap portion described in the response (allowing for GET_FMAP responses that contain an incomplete file map). If there is desire to give GET_FMAP a different name, like GET_IOMAP, I don't much care - although the term "iomap" may be a bit overloaded already (e.g. the dax_iomap_rw()/ dax_iomap_fault() functions debatably didn't need "iomap" in their names since they're about converting a file offset range to daxdev ranges, and they don't handle anything specifically iomap-related). At least "FMAP" is more narrowly descriptive of what it is. I don't think Darrick needs GET_DAXDEV (or anything analogous), because passing in the backing dev at mount time seems entirely sufficient - so I assume that at least for now GET_DAXDEV won't be shared. But famfs definitely needs GET_DAXDEV, because files must be able to interleave across memory devices. The one issue that I will kick down the road until v3 is fixing the "poisoned page|folio" problem. Because of that, v2 of this series will still be against a 6.14 kernel. Not solving that problem means this series won't be merge-able until v3. I hope this is all clear and obvious. Let me know if not (or if so). Thanks, John [1] https://lore.kernel.org/linux-fsdevel/20250421013346.32530-1-john@xxxxxxxxxx/T/#me47467b781d6c637899a38b898c27afb619206e0
