On 7/21/21 10:42 PM, Vivek Goyal wrote: > On Wed, Jul 21, 2021 at 08:48:57AM -0400, Vivek Goyal wrote: > [..] >>>> So is "dax=inode" enough for your needs? What's your requirement, >>>> can you give little bit of more details. >>> >>> In our use case, the backend fs is something like SquashFS on host. The >>> content of the file on host is downloaded *as needed*. When the file is >>> not completely ready (completely downloaded), the guest will follow the >>> normal IO routine, i.e., by FUSE_READ/FUSE_WRITE request. While the file >>> is completely ready, per-file DAX is enabled for this file. IOW the FUSE >>> server need to dynamically decide if per-file DAX shall be enabled, >>> depending on if the file is completely downloaded. >> >> So you don't want to enable DAX yet because guest might fault on >> a section of file which has not been downloaded yet? >> >> I am wondering if somehow user fault handling can help with this. >> If we could handle faults for this file in user space, then you >> should be able to download that particular page[s] and resolve >> the fault? > > Stefan mentioned that can't we block when fuse mmap request comes > in and download corresponding section of file. Or do whatever you > are doing in FUSE_READ. > > IOW, even if you enable dax in your use case on all files, > FUSE_SETUPMAPPING request will give you control to make sure > file section being mmaped has been downloaded. > Sorry for the late reply. I missed this mail as it is classified into the mailing list folder. The idea you mentioned may works. Anyway, the implementation details of the FUSE server is not strongly binding to the FUSE protocol changes in kernel. The protocol only requires that FUSE client shall be able to store FS_DAX_FL attr persistently in *some way*. The changes in kernel shall be general, no matter whether the FUSE server is FS_DAX_FL attr based or something else. -- Thanks, Jeffle
