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 stripped packages that aren't used on my systems. > >>>> Another point of .tar.gz usage (or even just .tar - modules are >>>> compressed, so tarball compression is unnecessary) - fs cluster size. >>>> Bunch of files will use more space than single file (approx by >>>> cluster_size/2 * files_count). >>> On the server this is pretty irrelevant and you have to unpack the files >>> on the target systems. So all you do is save a little space centrally >>> and put the load on the users. >>> >>>> Even we can mount tarball via fuse or use http://avf.sourceforge.net/ >>> AFAIK there is neither on LEAF and that is where it would be needed. And >>> it adds unnecessary complexity. This is for enthusiasts, not end users. >>> Please start thinking like an end user. >>> >>> .. >> End user may change NIC for some enough rare that isn't in base moddb >> support. And he'll need to use module autoprobing feature in that case - > There are systems where autoprobing fails, rare but true :-( Possibly due to limited RAM? > >> so end user should have all modules on local storage. In compressed or >> in uncompressed form. > Believe me, there are systems which don't have enough storage and for > these we need a more granular aproach. > >> 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).
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). > cheers > > 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
