Re: Please add the zuf tree to linux-next

[Miklos Szeredi <miklos@szeredi.hu>]

On Thu, Nov 14, 2019 at 3:02 PM Boaz Harrosh <boaz@plexistor.com> 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