roberts
Group: Members
Posts: 4983
Joined: Oct. 2003 |
 |
Posted: June 02 2006,05:21 |
 |
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
Edited by roberts on June 02 2006,05:29
|
.
DSL Market ,
Great VPS hosting provided by Tektonic
