no problem ...perhaps some of the time consumed is related to data transfer rather then compression. I had 5 seconds compared 1 second... in my case making an sfs of pup_rw containing ~30mb data using full and zero compression...pentium 3 machines with decent ide drives/cache.
Another point is mksquashfs has options for which part of the system is compressed and how duplicate files are handled... though the bulk of time savings are with compressing the main data.
Was your figure with the lower compression special build of mksquashfs..I am not clear on that. If so that does sounds interesting if we can have ~40% compression with only a 20% penalty. Loading times varied only a little...it was the save at shutdown that speed became a factor.
When making sfs files I do find up to 50% faster if I use sfs without lzma (standard squashfs) as apposed to with, with a size gain of 10-20%, but in those instances speed is not essential.
Some more scientifically compile statistics would be a good idea ...I will apply myself to that
mike
Partially automated remastering of sfs files
Just adding my remastering notes that have been gathered from the guys on the forum. Think they match up Artsown.
Removal of:
X seems to have exited uncleanly the last time you ran puppy
this is usually because of a power failure.
If not just wait 30 seconds to start
Another simple way to get around this is to just add to /etc/rc.d/rc.local:
When X is started, /etc/.XLOADED is created, so if X wasn't exited properly (like the classic "fsckme" flag: on a proper shutdown it will be deleted ; if it's not deleted you know the system has crashed).
If the periodic saving is used (or if the user manually saves with snapmergepuppy), then the saving happens while X is running, thus .XLOADED is also saved to the save file (mounted on /initrd/pup_ro1), so you need to delete it or X won't automatically start on next boot.
The same happens if you backup your save file.
ANSWER:
/etc/.XLOADED is one of the very few files you need not to copy into /tmp/etc while remastering .
Otherwise the dialogue is to be found in /usr/bin/xwin script .
The do not remove flash drive message....
usr/sbin/delayedrun..Lines 116-124 comment out. Breaks Puppy badly.
Removal of:
X seems to have exited uncleanly the last time you ran puppy
this is usually because of a power failure.
If not just wait 30 seconds to start
Another simple way to get around this is to just add to /etc/rc.d/rc.local:
Code: Select all
Code:
rm /etc/.XLOADED (Confirmed, this is the best one).If the periodic saving is used (or if the user manually saves with snapmergepuppy), then the saving happens while X is running, thus .XLOADED is also saved to the save file (mounted on /initrd/pup_ro1), so you need to delete it or X won't automatically start on next boot.
The same happens if you backup your save file.
ANSWER:
/etc/.XLOADED is one of the very few files you need not to copy into /tmp/etc while remastering .
Otherwise the dialogue is to be found in /usr/bin/xwin script .
The do not remove flash drive message....
usr/sbin/delayedrun..Lines 116-124 comment out. Breaks Puppy badly.
Ok makes sense...I was considering ONLY mksquashfs times (standard remaster and sfs save) where you would probably find a large speed difference but in your script ..cp of the whole system plus save will be taking a good chunk of the time. So I am not going mad 
..just my usual confused state.
For my saves obviously mksquashfs is the only factor since nothing else is used and speed of shutdown has to be good.
Not exactly comparing apples and oranges but useful info has been brought up regardless......
mike
..just my usual confused state.For my saves obviously mksquashfs is the only factor since nothing else is used and speed of shutdown has to be good.
Not exactly comparing apples and oranges but useful info has been brought up regardless......
mike
Mike,are you saying that one could theoretically shove all the contents of puppy onto a usb stick for example, all uncompressed, and that it would boot up really fast?
I was thinking that if they were all uncompressed at least you could tweak things, and it would all be done there and then without having to squash it up again.
I'm pretty much done with isos these days and just use vmlinux, initrd.gz, puppy main sfs and the syslinux cfg and the msg and pretty picture on boot.
I was thinking that if they were all uncompressed at least you could tweak things, and it would all be done there and then without having to squash it up again.
I'm pretty much done with isos these days and just use vmlinux, initrd.gz, puppy main sfs and the syslinux cfg and the msg and pretty picture on boot.
no lolMike,are you saying that one could theoretically shove all the contents of puppy onto a usb stick for example, all uncompressed, and that it would boot up really fast?
I was in my case referring to how I save on puppy.
What you might be after is making a full install on a usb stick...there have been threads on the subject in the past.
Closest I have is a frugal save file containing the full system...so like a full in a frugal buit thats aimed at fat32/ntfs partitions.
mike
Maybe, but the post highway could be littered with puppy roadkill of abandoned experimentsWhat you might be after is making a full install on a usb stick...there have been threads on the subject in the past.
It took me weeks to wonder why the sticks wouldn't boot puppy until a good old rcrn51 howto produced the magic code:
2. Plug in the flash drive but don't mount it. Type:
Code: Select all
Code:
syslinux /dev/sdxyLike you said, there was some good stuff brought up on remastering from those at the coalface. I'm handing out the canaries at the lift shaft
Hmm i would guess the method was to make the installer think the flash stick was a hard drive.
That info is gained from /etc/rc.d/PUPSTATE where usb and hard drives are listed separately ...moving over or adding the flash drive might be all thats needed the follow the hard drive procedure.
syslinux for booting or I usually use grub4dos with bootlace.com /dev/sd(x)
a full on a stick is probably less of a problem than pupmode 13 and speed wise few of use still have only usb1 around...I actually did run XP from an SD card on a netbook...was fine so I cannot see puppy being a problem.
mike
That info is gained from /etc/rc.d/PUPSTATE where usb and hard drives are listed separately ...moving over or adding the flash drive might be all thats needed the follow the hard drive procedure.
syslinux for booting or I usually use grub4dos with bootlace.com /dev/sd(x)
a full on a stick is probably less of a problem than pupmode 13 and speed wise few of use still have only usb1 around...I actually did run XP from an SD card on a netbook...was fine so I cannot see puppy being a problem.
mike