Page 1 of 2
Quirky multisession
Posted: Mon 06 Jan 2014, 22:37
by Ted Dog
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?
Posted: Tue 07 Jan 2014, 02:08
by Flash
The concept sounds good to me, but I don't understand what you mean by, "I wondered if those of us that use MS just for run in RAM speed have more than 1G." Please explain.
Also, would you still be booting only from USB flash drive? Would it be possible to run it from a multisession DVD?
Posted: Tue 07 Jan 2014, 02:58
by Ted Dog
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..
Posted: Tue 07 Jan 2014, 10:47
by mikeb
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
Posted: Tue 07 Jan 2014, 14:50
by Flash
Uh, I didn't realize MS meant Multi-Session. I thought it meant Microsoft.
Posted: Tue 07 Jan 2014, 16:54
by Ted Dog
Flash wrote:Uh, I didn't realize MS meant Multi-Session. I thought it meant Microsoft.
ok I can see it now... that is funny.
The limit with no layered filesystem is why this idea is uncompressed for use.
Posted: Tue 07 Jan 2014, 17:23
by mikeb
Uh, I didn't realize MS meant Multi-Session. I thought it meant Microsoft. Embarassed
ha ha so did I ... guess the brain cell was on loan to someone else.
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
Posted: Thu 16 Jan 2014, 16:27
by mikeb
Abandoned or feverently pursued?
mike
Posted: Thu 16 Jan 2014, 18:27
by Ted Dog
sidetracked by life and slacko64
actually did not bring dvd burner on this trip. I missed the smell of lazered plastic in the morning
Also hoping you could blaze this trail. My code for doing this is on a old disc that I havent recovered. Sounds like your methods are at least past v2 of puppylinux.
Posted: Thu 16 Jan 2014, 18:54
by mikeb
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
Posted: Fri 17 Jan 2014, 04:19
by 8-bit
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.
Posted: Fri 17 Jan 2014, 12:26
by RSH
Uh, I didn't realize MS meant Multi-Session. I thought it meant Microsoft.
That was my first thought as well!
Posted: Fri 17 Jan 2014, 12:30
by mikeb
That was my first thought as well! Laughing
you are just thinking about tarts who play with your modules...
mike
Posted: Fri 17 Jan 2014, 19:41
by mikeb
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.
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
then a dummy pupmode is used to bypass the union mount.
mike
Posted: Fri 17 Jan 2014, 20:23
by Ted Dog
wow did I read that correctly you are running in ram with only 512Ms of RAM hardware... if so sweet!
Posted: Fri 17 Jan 2014, 20:28
by mikeb
Ok would probably not fit in with a recent puppy but you are looking at 1GB plus.
I manually resized the tmpfs with swap added no problem so ended up with 450MB free.
I wondered about using sfs files but there is a unionfs-fuse option that would get around that.
mike
Posted: Fri 17 Jan 2014, 20:40
by mikeb
Ok htop ...but after adding swap and running stuff.
The initial boot showed only 42MB in use...similar to a full install as expected.
mike
Posted: Fri 17 Jan 2014, 22:15
by Ted Dog
Then a ram drive swap with compression would be doable gmartin I think posted somethng about that. Its suppost to save RAM space and be faster than hardware. should be seemless since it looks like any other swap.
Posted: Fri 17 Jan 2014, 23:13
by mikeb
compressed swap in ram...hmm it would seem to me a similar gain to simply loading the sfs into ram as is.
Since this full install in ram seems ok... you mention making a save of the whole thing as a shutdown option.
This in effect would be a very simple fast custom remaster.
mike
New look at use of RAM in system's operation
Posted: Fri 17 Jan 2014, 23:29
by gcmartin
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.