Typically, userspace file-systems serves in-coming requests via fuse
file-descriptor using some sort of threads-pool. This design often
yields complex locking schemes on internal data-structure. Funex tries
to avoid this problem by using a message-passing architecture, using
the following three stages:
- fuse-rx / fuse-tx threads
- core thread
- io-slave N-threads
Thus, all cache operations become lock-free operations from within
core thread. When the core thread wants to write meta-data blocks, it
uses page-forking. Of course, this is somewhat different from Tux3
frontend/backend architecture, but I guess you can see the influence.
Regards,
Shachar
On Thu, Jul 24, 2014 at 11:58 AM, Daniel Phillips dan...@phunq.net wrote:
Hi Sachar,
On Wednesday, July 23, 2014 4:43:35 AM PDT, you wrote:
In the past few month I developed Funex, a new (FUSE-based, GPL)
file-system. Although still in very early alpha stages, the basic
functionality seams to work fine. During the development process I
discovered again and again that many of the design-notes in tux3
mailing list have a lot useful ideas as well as insight into
file-system internals. In particular, the idea of using
frontend/backend architecture influenced Funex internal design.
I would like to thank you all for sharing this knowledge.
You are most welcome. Perhaps you could tell us a little more
about how you adapted the frontend/backend concept for use with
FUSE.
Regards,
Daniel
___
Tux3 mailing list
Tux3@phunq.net
http://phunq.net/mailman/listinfo/tux3
