Concerning trying to convince the father of slax to include and extensive array of driver
i have actually given up. it's hard to convince Tomas to anything... time will tell who was right in this case
in Porteus is under 4MB and covers 95% of wifi chipsets...
just checked and current 'extra-firmware' package for porteus-2.0 is 3.8MB
will also include boradcom-sta by default so we should have the same cover as in porteus-1.2 for wifi.
how much space is required for graphic drivers in porteus?
i think you are referring to a firmware required by radeon driver (other drivers have fw compiled in). it's 650KB uncompressed and always was included in Porteus. this is not going to change...
I guess 128k gives a compacter module
higher block size means smaller module but uses more memory to mount xzm and more CPU power to read from it.
here is how i understand the "block size" issue:
let's say you have a module containing small files only: 000-kernel.xzm is a perfect example cause most kernel drivers are about 100KB in size.
let's say udev is going to load 15 drivers from 000-kernel.xzm during boot time.
if you compress a module with 1MB block size and these drivers will be spread over whole xzm (worst scenario) then udev will have to read 15MB of data just to unpack 1.5MB of drivers. that's a huge waste of I/O thus CPU power (and causing slow boot).
if you compress a module with 128K block size (or even better 64K) then probably only about 2MB of data will have to be uncompressed to get an access to these 15 drivers.
my assumptions seems to be correct, let me qute Phillip Lougher (a squashfs creator):
Code: Select all
The smaller the buffer cache I/O block the less wasted I/O is performed.
For instance a Squashfs block overlapping 60 bytes into the last buffer
cache block @ 1K I/O size results in less wasted I/O than @ 4K I/O size.
and
Code: Select all
smaller buffer cache block size results in less I/O performed by Squashfs
reference:
link
i have done my own tests:
a) i have reduced block size in all modules from porteus-2.0 alpha from 256KB (default) to 128KB
b) attached one 3.0Ghz core to vbox session and reduced it's execution cap to 33%. this way i got env similar to pentium II 1000 Mhz.
result:
10% faster boot when using 128KB block size.
the drawback of this test was that it measured only CPU time needed for getting to the desktop. in vbox case reading speed was unlimited which is not a "real life" scenario.
if you take for example i7 CPU and some slow usb stick then higher block size can result in faster booting as usb reading speed would be a bottleneck and not the CPU power.
on the other hand if Porteus would be installed on a SSD drive with weak CPU (netbook with Atom CPU) then lower block size should be a pure winner.
another factor is a power needed for certain operations (this affects battery life).
lower block size is a winner here as less I/O means less CPU power needed to uncompress required data.
lower block size == longer battery life
i hope all it sounds reasonable
it's really hard to make a decision regarding default bs for modules in porteus-2.0.
many factors to take into account.
i think we could stick to default 256KB as user can always recompress the modules for lower block sizes (or even gzip/lzo compression) when needed.
If we go for 128k blocks, does it mean we will have to redo all modules?
nope - block size and even compression algorithm can be different. porteus kernel will accept them all.
What is the main difference between initrd (initialize ram disk) and initramfs (initialize ram file system); it is obvious they do the same, but please tell us why it is better
here they are:
a) initramfs can have any size (1MB, 10MB) and does not require providing a cheatcode to the kernel to tell about its size (initrd required 'ramdisk_size=some_value')
b) in porteus-2,0 case initramfs will be unpacked on tmpfs (RAM filesystem) so at the end on booting process unused data (binaries/libraries) can be deleted from it to free up the memory. initrd was taking full 2.6 MB of ram (6.6MB in slax-6.1.2 case), initramfs in porteus-2.0 should'n take more than 300KB as we need only busybox for shutdown, the rest can be deleted.
c) tmpfs mounted in /mnt/live folder can be very handy as we can use it from porteus directly. for example i have linked /run folder to /mnt/live/run (so i dont have to mount tmpfs twice and also blkid cache can be shared) and exported KDEVARTMP to /mnt/live/var/tmp so big kde4 cache files are always placed in RAM even when booting with 'changes=' cheatcode. this trick should benefit kde4 users (who are saving changes) in faster boot/overall desktop performance.
d) you can use multiple initramfs as they work in a layered structure (same as aufs+modules). this way we are going to have 2 initramfs in porteus-2.0: main one holding all utils/libs/linuxrc script and second one holding all drivers needed for pxe-boot (porteus-2.0 is going to have full support for all ethernet devices). second initrd will be loaded only by pxe clients so booting to normal session wont be slowed down even by a millisecond (btw - booting and shutdown speed of porteus-2.0 is much improved again, more to come in official porteus-2.0 changelog).
as far as i remember these are main differences in initramfs vs initrd battle.
Cheers