03.04.2015 14:02, Erich Titl пишет: > Hi Andrew > > Am 02.04.2015 um 22:35 schrieb Andrew: >> 02.04.2015 22:09, Mega пишет: > ... > >>>>>> 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, > Just for the fun of it I built a squashfs from the modules-geode > directory using the xz compression and did some comparison > > mega@leafbuilder:~/leaf/devel/packages/i386$ ls -l /tmp/geode.fs > -rw-r--r-- 1 mega mega 12869632 Apr 3 12:05 /tmp/geode.fs > > mega@leafbuilder:~/leaf/devel/packages/i386$ du -s modules-geode > 15936 modules-geode > > mega@leafbuilder:~/leaf/devel/packages/i386$ ls -l modules-geode.tgz > -rw-rw-r-- 1 mega mega 12879371 Mär 31 10:57 modules-geode.tgz > > The numbers imply that there is nothing to be gained in size over the > tarball using squashfs. The advantage of using a squashfs is that we do > not need to unpack the tarball for each file involved. This method is > clearly better than using the tarball and I would recommend replacing > the tarball with a squashfs file. This also makes automatic module > detection a lot more painless. We even may do automatic module detection at boot in that case, with modules.dep from build tree. Also, we may use .gz for squash - it's faster in decompress by at least twice. Or even use lz4/lzo - it's even more fast. We doesn't need high compression rate here - because most data is already compressed. > > For small systems though this may still be insufficient. I propose to > still keep the unpacked tarball in a directory on the sourceforge > server, so there is the possibility of a granular access to the > individual modules. Ok, server side storage isn't an our pain. > I looked up our modules files and I failed to find the squashfs module. > Should we decide to go the squashfs way, we obviously need to include > this. I will build a kernel for further tests Yes, AFAIR squashfs is disabled because we don't use it. We need to include it (possibly - as initmod module, or even compile in kernel - it isn't large). It'll be useful also for embedded systems like SOHO routers with small RAM amount, but with persist flash storage suitable for read-only squashfs rootfs storing - I want to make some experiments when I'll have enough free time. > 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
