On Wed, Jan 25, 2006 at 09:55:58AM +0100, Mark Phalan wrote:
> 
> Hi,
> 
> What would it take to get unionfs working for Solaris.
> From my understanding of the website FiST already supports Solaris
> but unionfs itself is GPL'ed. 

Originally, Unionfs was created using FiST, but since then it has been
heavily modified - so much so that the task of making it work on Solaris
might take more effort than reimplementing it (not necessarily from
scratch.) Of course, since Unionfs is GPL, you are free to use the
source according to the rules stated in the license. This is virtually a
non-issue if you are working on an academic or purely open source
project.

The FiST project can be used to generate SunOS compatible stackable
filesystems, but you can go only so far with the templates - you will
have to do some hand coding (which will probably be a lot for something
as complex as unionfs.) The latest supported Solaris version is 8, but
I vaguely remember hearing something about FiST and Solaris 9.

> Is the only way to get unionfs working on Solaris to do a re-implementation?

I believe that the best way would be to look at unionfs (for Linux) and
look for the rough edges; I am not familiar with the SunOS VFS
implementation, but I'd guess that it has the same basic ideas (there
is a very well defined set of properties each inode/SunOS equivalent
has, as defined by POSIX.) and therefore taking some "simple" FiST
generated fan-out (many lower filesystems being accessed by a single
stackable filesystem) filesystem for Solaris, and turning it to unionfs.

I am sure you have heard this before, but I have to say this...if you do
try to implement unionfs, make sure you design you data structures in
such a way that will make creating the code to do the actual unioning
simple. Also beware, I suggest you look at unionfs (for Linux) and see
what kind of things are happening, the worst thing that can happen to a
design is the realization that it is (near) impossible to implement
some functionality which is necessary for the program to be of any use.
There are some rather interesting behavioral requirements. For example,
if you try to truncate a file that's being executed, you should get
ETXTBSY back as an error, it does make sense that such thing would
happen, however small things like this make things harder.

I hope this helps,

Jeff.
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs

Reply via email to