On Fri, Feb 03, 2006 at 07:30:37AM -0600, Charles Duffy wrote: > I'm thinking it would be an interesting project to write a FUSE-based > (and thus userland) implementation of UnionFS in a higher-level language > such as Python. This would potentially make it easier to prototype and > observe the impact of logic changes such that semantics could be worked > out in a high-level, userland implementation before changes are made to > target the kernelspace implementation.
Coincidentally, two days ago, I got curious about FUSE so I decided to write a very simple fs in python (I invested about 2 hours into it, so it does not do much.) It is a nice, but _much_ higher level than VFS-style stackable fs. For the most part, you get a path, and based on it you can decide what to do, which is very different from VFS-style code, where you have a mix of inodes, dentrys, superblocks, etc. > I'm not promising to put any substantial amount of work into this > immediately... but particularly if documentation, separate from the > code, as to the present exposed semantics and algorithms used in the > implementation (ie. whitelist logic) is available, it may well make it > onto my idle list. I my opinion, most of UnionFS complexity comes from the fact that we have to access lower inodes and dentries and update our (UnionFS) inodes and dentries so that the VFS doesn't feed the user stale dentry cache data. The core "algorithms," such as copy-on-write, the use of whiteouts, etc. aren't too bad by themselves, but when you mix them with how Linux VFS works, you get the ~12000 lines of C you see now. My guess is, if you are proficient in python you should be able to write a simple unionfs-like fuse fs in a day or two. But the hard part would be fixing it up to follow all the unix semantics: eg. return ETXTBSY when a process tries to truncate a running executable, etc. Jeff. _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
