Hi Andrew at 23.04.2012 10:07, Andrew wrote: > 11.04.2012 09:36, Erich Titl написал: >> Hi Andrew >> >> at 22.04.2012 23:20, Andrew wrote: >>> Hi all. >>> I'm thinking about some improvements that can be useful in future, >>> especially on tiny systems, and that should be added before 5.0-beta >>> release if they'll be accepted as useful: >>> >>> 1) Split single solid initrd to multiple files, for ex. - basic initrd >>> with binaries, and additional files with kernel modules (usb variant, cd >>> variant, etc). Syslinux supports multiple initrds: >> Does Grub support them too? > Yes.
Could you refer me to the docs? >>> http://www.syslinux.org/wiki/index.php/SYSLINUX#INITRD_initrd_file >>> This can save some valuable space on tmpfs. Also this allows to add >>> single arch-independent initrd, and arch-dependent initrd additions with >>> modules. >> Sounds reasonable, but see above. I believe the cpio initrd can be >> concatenated to a single file. > I think that concatenating isn't a good idea. But repacking from 2 cpio > archives to one image is possible in any case. > > Also there is a possibility to integrate some of initramfs into kernel > image. >>> 2) Add support of zram - compressed ramdisk (compressed block device in >>> memory, which can be used as swap or as base device for some >>> filesystem). But I still unsure in what way we should use it: as typical >>> 'swap in RAM' device, or as block device(s) instead of tmpfs ones. In >>> 1st case tmpfs should be pushed in the 'swap' first, and it looks more >>> flexible, but 2nd case has it's own advantages. >> Would the compression overhead on slow (tiny) machines not overcome the >> benefits? Actually we don't need swap at all, and then having it to >> compress/decompress mhhhh.... >> >> cheers >> >> Erich >> > This can be switcheable feature. 'swap' will be used for rarely-accesed > data, and compression/decompression speed of LZO is enough high (just > 2-3 times lesser that access to uncompressed ramdisk on modern hardware; > for legacy hardware it'll require testing - but I don't think that it'll > be dramatically slow; LZO is enough fast algorithm). It'll be good for > log storing (which can be up to some hundreds of MBs per day) and so on. I was refering to the swap file where IMHO compression is a resource hog. A compressed filesystem for logging would be good. cheers Erich
smime.p7s
Description: S/MIME Kryptografische Unterschrift
------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
