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. >>> 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 :-( > 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 cheers ET
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ 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
