| 1 |
On Tue, 2020-06-23 at 01:17 +0900, Kaoru Esashika wrote: |
| 2 |
> Thank you for the reaction, Luca, Michał. |
| 3 |
> |
| 4 |
> I will expand my blog post soon. Thank you, Luca. |
| 5 |
> |
| 6 |
> I want to answer the question from Michał. |
| 7 |
> |
| 8 |
> > 1. From our talking you indicated that FUSE has both high-level and low- |
| 9 |
> > level API. However, the post only hints at it. Could you explain both |
| 10 |
> > shortly and why you've chosen the one you've chosen? |
| 11 |
> |
| 12 |
> There are some FUSE libraries which I can choose. But actively |
| 13 |
> maintenanced ones are pyfuse3 and libfuse (both are developed by the |
| 14 |
> same person). |
| 15 |
> pyfuse3 is an asynchronous python library. I call it 'low-level' |
| 16 |
> because functions that should be implemented are called with inode |
| 17 |
> arguments. |
| 18 |
> libfuse is a C library. It has two interfaces, high-level synchronous |
| 19 |
> one and low-level asynchronous one. The difference between the two is |
| 20 |
> whether arguments are path or inode. |
| 21 |
> So, with the exception of libraries that are no longer maintained, the |
| 22 |
> only choice is pyfuse3. |
| 23 |
> |
| 24 |
> > 2. How are you planning to deal with the essential problem that |
| 25 |
> > the underlying directory tree may consist of multiple filesystems with |
| 26 |
> > different files having colliding inode numbers? |
| 27 |
> |
| 28 |
> VFS in the kernel and programs in userland expects consistency with |
| 29 |
> regard to inode, so Fusebox should provide a unique inode for each |
| 30 |
> file. |
| 31 |
> Fusebox can do this by finding out which device the file belongs to. |
| 32 |
> Then remember mappings from/to device-inode pairs to/from 'virtual' |
| 33 |
> inode. |
| 34 |
> However, I worried this solution hits performance since it potentially |
| 35 |
> causes many stat() system calls. |
| 36 |
|
| 37 |
This sounds a bit like premature optimization problem. Let's focus |
| 38 |
on getting a working solution first. You can look into improving |
| 39 |
performance with different inode solution later on. |
| 40 |
|
| 41 |
> |
| 42 |
> > 3. How do other passthrough filesystems deal with the same problem? |
| 43 |
> > What are the advantages/disadvantages of different approaches you've |
| 44 |
> > considered, and why did you chose this solution? |
| 45 |
> |
| 46 |
> I investigated the high-level interface of libfuse. It caches the |
| 47 |
> reply of the user program. and automatically convert inode and path. |
| 48 |
> So the high-level interface of libfuse will affect the problem. |
| 49 |
> I also investigate sandboxfs ( https://github.com/bazelbuild/sandboxfs |
| 50 |
> ). I think it take same strategy to Fusebox. |
| 51 |
> sandboxfs construct filesystem tree virtually on memory and notice |
| 52 |
> virtual inode to user application. |
| 53 |
> This approach may hit performance because of frequent stat() call, but |
| 54 |
> I cannot think better approaches. |
| 55 |
> |
| 56 |
> Thank you for your reply and support. |
| 57 |
> |
| 58 |
> Would you mind if I publish this mail on my blog, Michał? It was a |
| 59 |
> worthwhile discussion and I'd like to share it on my blog. |
| 60 |
> |
| 61 |
|
| 62 |
Sure, please include anything that can help your readers understand |
| 63 |
what's going on with the project and why. |
| 64 |
|
| 65 |
|
| 66 |
-- |
| 67 |
Best regards, |
| 68 |
Michał Górny |
Archives