Hi Folks I have been able to test the upgrade script successfully using a squashfs file as the source for the modules. This leads us to the question if we should use this method as a means to distribute the modules.
The use of a squashfs file instead of a compressed tarball for the distribution of a directory tree is intriguing indeed. It does not need to unpacked before use and if the target system inherently knows how to handle a squashfs everything works fine. For LEAF, especially for the case of the upgrade function, there are a few more things to be considered. My tests have shown that using a poor line the probability of a transmission failure is much higher with a single big file than with a number of small files. Also it is hardly ever necessary to distribute the entire module tree for a certain system. Typically less than 10 percent of the modules are ever needed. There is hardly any difference in file size between a squashfs and a compressed tarball, so the only benefit in using a squashfs is the capability to access its content without the need to decompress it. The upgrade script right now can handle both, using a squashfs or fetching single files from the server at sourceforge. My test worked better when using single files. I tested using a wireless connection and a few times I had transmission failures due to radio drops. Using single files worked more consistantly. I personally doubt that there is a need to keep the modules in a single file on the server. For big storage media the difference in size between a compressed fiel and a directory tree is irrelevant, for small media even the tarball or the squashfs are too big. On small sysems the squashfs can be used copying it to temporary storage. On the downside squashfs needs adaptation of busybox and the kernel. Also we need to create the squashfs files when building the package directory on the server. We need to decide - do we really need a single file for the modules on the server? - is a compressed tarball or a squashfs the right solution if there is to be a single file? For small systems the tarball is not suitable, the squashfs might be. There may be a problem for a directory tree on certain isofs formats, which may not be capable to handle either case sensitivity and/or long filenames. It is possible that the tarball was chosen for these reasons. I am pretty confident that we can manage an iso 9669:1999 format which does not have the restrictions of the old iso 9660 formats for CD distributions. cheers ET
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
