On Wed, Aug 01, Erez Zadok wrote: > There are three other reasons why Unionfs and our users like to have > multiple writable branches: > ... > And yes, it does make our implementation more complex. And error-prone and unflexible wrt to changes. When XIP was introduced, unionfs crashed all over this changes. I don't know if this has changed yet. Not speaking of other issues like calling back into VFS (stack usage), locking problems and so on. > 3. Some people use Unionfs in the scenario described in point #2 above, as a > poor man's space- and load- distribution system. Some of our users like > the idea of controlling how much storage space they give each branch, and > how much it might grow, and even how much CPU or I/O load might be placed > on each of the lower filesystems which serve a given branch. That way > they worry less about the top-layer's space filling up more quickly than > expected. Now Unionfs was never designed to be a load-balancing f/s (we > have RAIF for that, see <http://www.filesystems.org/project-raif.html>), > but users seems to always find creative ways to [ab]use one's software in > ways one never thought of. :-) And this has nothing to do with unioning ... > BTW, does Union Mounts copyup on meta-data changes (e.g., chmod, chgrp, > etc.)? No. But it was proposed during on of the last postings. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
