Quirky multisession
Quirky multisession
The whole slow flashdrive and/or harddrive to run the latest Q6 offering has me bummed out dudes...
I have 4Gs of RAM on one box and 8G of RAM on my lappy. Q6 should run fine in RAM. But its not an option....
So I wondered if those of us that use MS just for run in RAM speed have more than 1G.
I idea is to run Q6 as is uncompressed in RAM (est. 300-400M) let it do its thing. And when its time to shutdown call its backup routine and save the resulting file snapshot back as a multisession.
Next reboot reload backup file and ask Q6 to restore from backup..
Can anyone poke holes in this consept? add ideas?
I have 4Gs of RAM on one box and 8G of RAM on my lappy. Q6 should run fine in RAM. But its not an option....
So I wondered if those of us that use MS just for run in RAM speed have more than 1G.
I idea is to run Q6 as is uncompressed in RAM (est. 300-400M) let it do its thing. And when its time to shutdown call its backup routine and save the resulting file snapshot back as a multisession.
Next reboot reload backup file and ask Q6 to restore from backup..
Can anyone poke holes in this consept? add ideas?
1G would be the minimum ram needed to pull this off. This would be a light wrapper to take compressed image storied inside inird ( like fat dog does ) expand in RAM like fatdog but into a RAM files system then switch Into normal Q6 loader routine.
Either boot would work. Heck even frugal style. Idea is tiny script to move backup files to a more permanent media when requested by user. System would always boot like pfix=ram and then replace with backup to gain last session. Not a wonderful idea but a way of working within limits..
Either boot would work. Heck even frugal style. Idea is tiny script to move backup files to a more permanent media when requested by user. System would always boot like pfix=ram and then replace with backup to gain last session. Not a wonderful idea but a way of working within limits..
Hmm why uncompress.... all my sfs load to ram.... might as well minimise ram usage. With puppy doing this with 512mb works happily and there is 512mb swap. Ok not so clever if you had a large pup, full open office and other such beasts...then 1GB is the sweet spot.... slax with the big stuff is happy doing similar in that.
saves are sfs files too loaded to ram... all seems to sit cosily...
So just saying compressed works fine and helps make a smooth working system. Would mean less hacking for your idea.
mike
saves are sfs files too loaded to ram... all seems to sit cosily...
So just saying compressed works fine and helps make a smooth working system. Would mean less hacking for your idea.
mike
ha ha so did I ... guess the brain cell was on loan to someone else.Uh, I didn't realize MS meant Multi-Session. I thought it meant Microsoft. Embarassed
Ok so you are thinking of having effectively a full install sat in a ramdisk...no unionfs.... gotcha.
Well doable...it would resemble my image file save... with that I extract to a save file the full system .... it was then loaded by the initrd and pivoted into....no layers
Idea was to give a frugal like install so ok for ntfs and fat but have the unionless running and low ram of a full install. Obviously there is no save system as such as you have a full install in an image file.
It works..all my pups include this option... so really the only difference would be to extract the sfs into a tmpfs and pivot into that.
As i type I realise that slitaz is either very similar to this (giant initrd perhaps) or the same...been a few years since i played with it...they definitely make a snapshot at shutdown but they aim to be in the 30-50mb region.
Yes in tmpfs need a pile of ram but that's pretty common nowadays. Will also be slow at shutdown IF a save of the system is needed..of course thats optional and it also depends if compressed or not.
mike
No problem...just wondered why you went suddenly quiet.
Hmm so you think it might just tease my curiosity to try this out.... a fiddle with initrd should be enough for a quick test.... only needs combining 2 methods into one.
Ok well theory says this will work so will put it into practise.... or is that practice...
mike
Hmm so you think it might just tease my curiosity to try this out.... a fiddle with initrd should be enough for a quick test.... only needs combining 2 methods into one.
Ok well theory says this will work so will put it into practise.... or is that practice...
mike
I do not see why one could not make an SFS out of the Quirky 6.02? usfs file and then modify a initrd file to load it into memory and put it all on an ISO.
It would take some reverse engineering, but one should be able to do it.
The main thing is to if the usfs file is compressed.
I had tried renaming the extension to SFS and when i CLICKED on it afterward, the file system showed up.
But I am dumb. One might run dir2SFS on the root directory in that usfs file.
It would take some reverse engineering, but one should be able to do it.
The main thing is to if the usfs file is compressed.
I had tried renaming the extension to SFS and when i CLICKED on it afterward, the file system showed up.
But I am dumb. One might run dir2SFS on the root directory in that usfs file.
Ok had a few spare moments so did the promised test.
After one failure as it needed initrd folder making (doh) it booted just fine. Obviously the ram hit is higher...I tested 4.12 as I had 512mb ram to hand...its 92MB sfs consumed ~260MB in tmpfs leaving 108 to spare... normally i add swap to the tmpfs but that was not happening since the tmpfs folder was moved.
Screen shot of it running...note no mounted folders in initrd and no drives mounted..truly floating in ram as I like it and not a unionfs in sight.
Took ~ 10 seconds to load the sfs on a pentium 3.
The core code doing the job which just uses common variables.
then a dummy pupmode is used to bypass the union mount.
mike
After one failure as it needed initrd folder making (doh) it booted just fine. Obviously the ram hit is higher...I tested 4.12 as I had 512mb ram to hand...its 92MB sfs consumed ~260MB in tmpfs leaving 108 to spare... normally i add swap to the tmpfs but that was not happening since the tmpfs folder was moved.
Screen shot of it running...note no mounted folders in initrd and no drives mounted..truly floating in ram as I like it and not a unionfs in sight.
Took ~ 10 seconds to load the sfs on a pentium 3.
The core code doing the job which just uses common variables.
Code: Select all
mount tmpfs /pup_new -t tmpfs -o size=${SIZEFILLK}k;check_status $?
echo -n "Mounting /dev/${PDEV1} on (/initrd)/mnt/dev_ro1..." >/dev/console
mntfunc -o rw,noatime -t $FSTYPE /dev/$PDEV1 /mnt/dev_ro1;check_status $?
echo -n "Loading contents of pup_${PUPPYVERSION}.sfs to ramdisk..." >/dev/console
losetup /dev/loop1 /mnt/dev_ro1/$PUPSFS
mount -r -t squashfs -o noatime /dev/loop1 /mnt/data
cp -a /mnt/data/* /pup_new;check_status $?
mkdir /pup_new/initrd #or it cannot pivot!!
umntfunc /mnt/data
umntfunc /mnt/dev_ro1
mike
- Attachments
-
- thing.png
- (186.51 KiB) Downloaded 1201 times
New look at use of RAM in system's operation
Be careful on this, as, you are treading on using a system to its potential without all of the intermediates that were used when RAM was limited. Your findings are a worthy demonstration of what's possible. You are on to something here.
This could be a game-changer with the benefits you are demonstrating. A RAM based system in all its glory.
There seems to be a potential that this process would work no matter what media, disc or disk, is used by the system at boot. Thus the considerations of boot media may reduce a developer's concern to a simple process of assessing peripherals and adjusting timings for data discovery at boot time. Thus, this would reduce to a singularity, in theory. Hope this is depiction is accurate.
Hope this helps.
This could be a game-changer with the benefits you are demonstrating. A RAM based system in all its glory.
There seems to be a potential that this process would work no matter what media, disc or disk, is used by the system at boot. Thus the considerations of boot media may reduce a developer's concern to a simple process of assessing peripherals and adjusting timings for data discovery at boot time. Thus, this would reduce to a singularity, in theory. Hope this is depiction is accurate.
Hope this helps.