Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] CastFS File-System

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] CastFS File-System
  • Date: Mon, 9 Oct 2006 11:06:53 -0700

On Mon, Oct 09, 2006 at 10:40:16PM +0500, Alexander Tsamutali wrote:
> Very interesting. One question though. How portable is this fs? I
> remember that fuse works only on linux and freebsd kernels. What if
> someone want's to port sorcery on other systems?

Well, the system wont stop working, instead they loose some
functionality. Namely they'd revert back to traditional logging
installwatch (not to be confused with the translated installwatch we
experimented with) and use that instead. Until a compatible overlay
filesystem was found/ported to that platform.

The decision to use a filesystem was a difficult choice. Unfortunatly
glibc is simply not designed to interface with installwatch's translation
feature. There are holes that effect it quite drastically, and while
it might be slightly more portable in theory, in practice its not a
viable solution. We've recieved confirmation from the glibc developers
that they won't compromise other requirements to better support the
installwatch approach. It was clear that a kernel based approach was
the only realistic solution.

We had two main goals:
It has to work transparently with minimum fuss
-- this is true in theory w/ installwatch, in practice it wasnt
We shouldn't have to spend much time maintaining it
-- needs to be its own project, or work with something that has a stable api

In order for it to "just work" we had to go into the kernel, we proved
we can't rely on glibc. We looked at several in-kernel type modules,
namely unionfs (but there were others), as well as some fuse/lufs based
versions. In the case of in-kernel modules, while they probably would
work almost out of the box, they're not portable, and we run the risk
of needing to modify them whenever the internal kernel api changes
(which it does because the devs wont standardize it (and thats ok)).
We had to pick a userspace tool. Between fuse and lufs, fuse seems more
active and the logical successor to lufs. The api to fuse is pretty
stable, and theres an active community behind it, several other popular
filesystems using it, and so theres motivation beyond castfs for people
to keep it working. That helps satisfy the second goal, we minimize the
amount of code we have to maintain by using a stable/popular api. Since
fuse is popular, that gives us good chances for "free" portability because
if another platforms get popular, someone might port fuse for us, and
our fs will continue to work.


-Andrew

--
_________________________________________________________________________
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page