clacker, Seeing that both methods produce the same result. Also seeing my original method does indeed work upon initial load. My gut feeling is that this is a cache issue with unionfs. That maybe with this level of unionfs and this kernel we don't have much control over cached results of the union space. For example, if I unload several other unc's and then load them up again, including the myapp/dd thing. It, myapp.unc works once again. This tells me that the cache changed enough for the path to work correctly. Maybe it is too optimistic to be able to offer such dynamic loading and unloading. Loading ok. Don't allow unloading of unc. With 64 cloops I think this is workable. Another point for dis-allowing of unc type extensions is the copy-on-write of unionfs. Take for example the myapp/dd example. This is a read-only compress and mounted. Yet I can edit /bin/dd and add another line to the dd shell script. This is allowed and is automatcially copied to the top most branch /ramdisk/bin. Now if I unload the app, all these other modified files remain. That could get ugly. Seems to me to be better to keep things in tack and not only avoid the possible cache issues but orpaned files as well
Quote (roberts @ June 02 2006,01:21)
..we don't have much control over cached results of the union space..
I think I'm out of my league here but I was looking up unionfs a couple of days ago, and I came across this -
"* Unionfs does not provide cache coherency. What this means to you is that if you directly modify the lower-level branches, then Unionfs will get confused. You can tell Unionfs to throw out its cache and recreate all of its objects (lazily), by running "uniondbg -g UNION".I could handle *.unc extension not being removable since the will dissapear on restart anyway, and it's not so different than the *.dsl packages now except for the memory usage.
My concern is that if you can't overwrite any existing files you couldn't make a unc extension for gnu-utils, which I personally find important. It replaces a lot of the busybox functions with the real GNU ones. Things like rm, cat, and sleep. When you scramble those functions mydsl-load no longer works.
I'll try uniondbg that was included in the unionfs.dsl extension to see if that helps.I have booted with unionfs option and now I can see unionfs mounted on various directories.
Then I download opera.unc and I save it in /ramdisk/tmp.
'mydsl-load opera.unc' returns a cloop error.
So i mount hdb on /mnt/hdb, mount the standard opera.uci and everything is fine.
Then I umount /opt/opera850 and try to reload the .unc, evrything freezes.
There's one thing I don't understand:
/ramdisk on /ramdisk
is that correct?I tried the uniondbg from the compile that I did. I get a "New generation" number but to no avail.
Union space overlay works when not run from a mounted compressed image. This is something that I had already tested, i.e., loading of .dsl's For example tar -C / -zxvf gnu-utils.dsl writes into the /ramdisk/bin, etc and works as expected. Real files and directories written into the union space work fine. But what we are expecting is an overlay from another mounted compressed image. What is interesting is that complementary compressed images seem to work fine, not compressed image overlays. Are we expecting more than the current capabilities of unionfs?
Still even the advantage of complementary compressed images seem to be worth the effort.