Op Wo, 24 augustus, 2005 11:18 am schreef Erich Titl: > Eric > > > [EMAIL PROTECTED] wrote: > >> >> I don't follow you here. Why do you wan't to use loop mounted cramfs? >> Does >> it use RAM or ROM (Flash/HD/Floppy/..). The advantage of full RAM based >> systems is that you can unmount the storage media. Besides the >> footprint of Bering-uClibc with base packages is only ~8Mb. > > Yes, but look at it when it holds ipsec, ssh, samba, squid... > True, that would be somewhat bigger, but not more than 2 Mb or so with this list.
> > A loop mounted cramfs looks (for read_only operations) exactly like a > part of the file system tree. The benefit of this is that, even on ram, it > cannot be trivially modified and it takes a lot less RAM space because it > compresses its contents. > > For example if we had all the /bin in a cramfs called bin.cfs which > would sit at / > > we could mount > > mount -o loop /bin.cfs /bin > > and the space needed by bin.cfs would be a lot smaller than if the > individual files in /bin would be installed normally. > > The same is true for all read_only components, like /lib /sbin /usr/bin > How would such a thing be implemented for all binaries? Cramfs is ro so you can't populate a loop mounted cramfs. This would mean that you either put all /bin, /sbin, ... binaries in seperate cfs files and don't have packages anymore, put a "bin.cfs" in every package containing the binaries and make tons of mount points or create a cramfs within your running system from the loaded packages and still need the initial amount of RAM ... Besides, you can also lzma your programs and have the same space savings. How do you see a way to create f.e. bin.cfs and still be able to install packages? Eric ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
