On Tue, 2020-06-23 at 01:17 +0900, Kaoru Esashika wrote:
> Thank you for the reaction, Luca, Michał.
> 
> I will expand my blog post soon. Thank you, Luca.
> 
> I want to answer the question from Michał.
> 
> > 1. From our talking you indicated that FUSE has both high-level and low-
> > level API.  However, the post only hints at it.  Could you explain both
> > shortly and why you've chosen the one you've chosen?
> 
> There are some FUSE libraries which I can choose. But actively
> maintenanced ones are pyfuse3 and libfuse (both are developed by the
> same person).
> pyfuse3 is an asynchronous python library. I call it 'low-level'
> because functions that should be implemented are called with inode
> arguments.
> libfuse is a C library. It has two interfaces, high-level synchronous
> one and low-level asynchronous one. The difference between the two is
> whether arguments are path or inode.
> So, with the exception of libraries that are no longer maintained, the
> only choice is pyfuse3.
> 
> > 2. How are you planning to deal with the essential problem that
> > the underlying directory tree may consist of multiple filesystems with
> > different files having colliding inode numbers?
> 
> VFS in the kernel and programs in userland expects consistency with
> regard to inode, so Fusebox should provide a unique inode for each
> file.
> Fusebox can do this by finding out which device the file belongs to.
> Then remember mappings from/to device-inode pairs to/from 'virtual'
> inode.
> However, I worried this solution hits performance since it potentially
> causes many stat() system calls.

This sounds a bit like premature optimization problem.  Let's focus
on getting a working solution first.  You can look into improving
performance with different inode solution later on.

> 
> > 3. How do other passthrough filesystems deal with the same problem?
> >  What are the advantages/disadvantages of different approaches you've
> > considered, and why did you chose this solution?
> 
> I investigated the high-level interface of libfuse. It caches the
> reply of the user program. and automatically convert inode and path.
> So the high-level interface of libfuse will affect the problem.
> I also investigate sandboxfs ( https://github.com/bazelbuild/sandboxfs
> ). I think it take same strategy to Fusebox.
> sandboxfs construct filesystem tree virtually on memory and notice
> virtual inode to user application.
> This approach may hit performance because of frequent stat() call, but
> I cannot think better approaches.
> 
> Thank you for your reply and support.
> 
> Would you mind if I publish this mail on my blog, Michał? It was a
> worthwhile discussion and I'd like to share it on my blog.
> 

Sure, please include anything that can help your readers understand
what's going on with the project and why.


-- 
Best regards,
Michał Górny