02.04.2015 22:09, Mega пишет: > Am 02.04.2015 um 16:27 schrieb Andrew: >> 02.04.2015 16:34, Erich Titl пишет: >>> Hi Andrew >>> >>> Am 02.04.2015 um 12:35 schrieb Andrew: >>>> 02.04.2015 13:16, Erich Titl пишет: >>>>> Hi Andrew >>> ... >>> >>>>>> Single tarball is easier for update than hundreds of small files. >>>>> No it is not, if you have insufficient space. It is just a bloody >>>>> pain >>>>> in the butt. And then what is IT for if we cannot automate tasks. >>>>> >>>>> Maybe you have unlimited memory and storage on your target system, >>>>> but >>>>> this is not the 'normal' case. >>>>> >>>> LEAF isn't targetted just for small systems. I use it on multicore >>>> servers - border/internal routers, BRAS servers... >>>> Also, hundreds of small files on local storage will consume more space >>>> than single tarball. >>> Correct, but you have enough storage. I am not oposed to keep the >>> tarballs, but automatic granular upgrades with little storage require >>> granular file access. >> 64-128M IDE DOM. > > I have systems with 8-16 MB :-( We may leave moddb + modules.squashfs - add to moddb ignorelist all modules that were copied from squash during init, so moddb will be saved empty/with custom modules; and for limited systems you'll have functional similar to older. > >>> >>>> From other side, we may do other trick: we may store modules in >>>> squashfs instead of tgz, and mount it instead of unpacking. And >>>> even we >>>> may remove moddb.lrp - just mount this squashfs at boot, probe >>>> modules, >>>> copy list of iptables-related modules + loaded modules into ram, and >>>> unmount module storage. This will save RAM on small systems, and >>>> simplify update handling :) >>> How much more do you think you can compress the data? Let's assume you >>> have about 20MB of storage available, can you meet that? I believe >>> leaving away some of the modules depending on the target hardware might >>> do the trick, but it leads us more individual target architectures. I >>> for once believe that our geode package, geared most of the time >>> towards >>> ALIX systems (I looked in the geode config patch) has a heavy overload >>> of modules which will never be used. On the other hand I am opposed to >>> the idea of keeping unneeded, redundant code on a system for the rare >>> case of a NIC change. Redundant for me are modules kept in more than >>> _one_ of the following. >>> >>> -initmod.lrp >>> -moddb.lrp >>> -modules.tgz >> There's 15MB modules.tgz size on fat i686 release. moddb.lrp - 2MB, but >> we should remove it if we'll have modules packed into squashfs (we don't >> need to place custom modules into system). initmod is relatively small >> (less than 1MB). > > Still holds far too much which are not really used. We could try to > remove them at the end of init. > We may even remove all loaded modules (except iptables and dependent) at end of init. But this should be switchable behavior. >> >> Also IMHO we should remove lot of drivers from i486/geode (for ex., SCSI >> RAID controllers and so on - they are unneeded, a lot of NIC drivers - >> for ex., PCI-E cards drivers, and so on). > > Yes > > ET > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > > > _______________________________________________ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
