On Thu, Nov 14, 2019 at 3:02 PM Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: > At the last LSF. Steven from Red-Hat asked me to talk with Miklos about the fuse vs zufs. > We had a long talk where I have explained to him in detail How we do the mounting, how > Kernel owns the multy-devices. How we do the PMEM API and our IO API in general. How > we do pigi-back operations to minimize latencies. How we do DAX and mmap. At the end of the > talk he said to me that he understands how this is very different from FUSE and he wished > me "good luck". > > Miklos - you have seen both projects; do you think that All these new subsystems from ZUFS > can have a comfortable place under FUSE, including the new IO API? It is quite true that ZUFS includes a lot of innovative ideas to improve the performance of a certain class of userspace filesystems. I think most, if not all of those ideas could be applied to the fuse implementation as well, but I can understand why this hasn't been done. Fuse is in serious need of a cleanup, which I've started to do, but it's not there yet... One of the major issues that I brought up when originally reviewing ZUFS (but forgot to discuss at LSF) is about the userspace API. I think it would make sense to reuse FUSE protocol definition and extend it where needed. That does not mean ZUFS would need to be 100% backward compatible with FUSE, it would just mean that we'd have a common userspace API and each implementation could implement a subset of features. I think this would be an immediate and significant boon for ZUFS, since it would give it an already existing user/tester base that it otherwise needs to build up. It would also allow filesystem implementation to be more easily switchable between the kernel frameworks in case that's necessary. Thanks, Miklos
