On Sat 10 Sep 2005 at 05:02AM, Daniel Johnsen wrote: > Hi there, > what about a port of Unionfs to Solaris ? > I read this wouldn't be too hard for someone who knows about filesystems in > Solaris.
Daniel, If we could, let's move this over to zones-discuss (and thanks for the good followups). I've copied zones-discuss; those wishing to catch up on this thread should see http://www.opensolaris.org/jive/thread.jspa?threadID=2221&tstart=0 > I want to create 10 Zones, for 10 friends of mine. What I have to do > now is COPY all the neccessary files from /bin/.. /lib/.. /sbin/.. to > EACH zone, this means I have got 10x wasted space. I think this statement is inaccurate. *By default* zones use the loopback filesystem, lofs(7fs), to import r/o copies of /bin, /lib, etc. into each zone. The packaging subsystem has been enhanced to be cognizant of these choices, and it's possible to import additional directories. Furthermore, the packaging subsystem knows how to create zones using "factory fresh" configuration files; that's why each new zone has a pristine /etc/passwd, for example. On a stock S10 system, each zone consumes about 65 MB of disk space, most of which is in /var and /etc. Some of that space is possibly waste (for example, 6.7M of this space is some example database that the application server places in /var, and 28M is some sort of gconf goop); we're looking at ways to reduce that consumption. > With Unionfs I could create the perfect solution: Create a directory > /opt/zones-template, and copy all the neccessary files into it. You are correct that unionfs's functionality is a superset of lofs, and that it provides significantly more semantic power. But it isn't the case that 10 zones consumes a massive amount of disk space. If I recall correctly, we did consider the creation of such a filesystem during the development of zones, but decided to hold off because: - It looked substantially challenging - lofs was "good enough" for the near term (and actually needed some significant work done to it just to get it there) - Some hesitation surrounding the administration model for translucent filesystems; one may recall unwhiteout(1) and lsw(1) from TFS as examples of the resulting ugly artifacts. See: (http://www.rahul.net/cgi-bin/userbin/man?topic=unwhiteout§ion=1) and (http://www.rahul.net/cgi-bin/userbin/man?topic=tfs§ion=4) I've not looked hard at unionfs, but I'm concerned about the amount of complexity it brings to the table. From the unionfs webpage: $ unionctl /mnt/union --add --before /mnt/cdrom1 --mode rw /mnt/changes Makes my head hurt; as does the need to invoke uniondbf -g /mnt/union to "force revalidation of the union." Anyway, I'd invite anyone wishing to take a shot at a union-style FS for Solaris to go for it; it might also be interesting to speak with the unionfs team at SUNYSB about a port to OpenSolaris; this might make an interesting project for a masters or undergraduate student. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
