Puppy RamBoot - Everything (including save file) in RAM
Puppy RamBoot - Everything (including save file) in RAM
I've hacked the 4.3.1 init script to bring you a fabulous new feature.
The ramboot option enables you to load all of your sfs files and your save file into RAM and run completely diskless. Of course you need to keep these files small enough to fit in the amount of RAM you have, leaving some space for the OS to operate. You can then use the hdparm utility to shut down your hard drive (assuming you're running without a swap space) , saving power and reducing noise. Plus you'll get even faster performance. The downside is, none of your changes will be persistent (at least not yet, I may, in the future, provide a shutdown script that copies your save file back to disk). So the procedure is: set up your save file how you want it, then use the ramboot option when you're not planning on doing anything you'd want to save.
To try out ramboot, replace your initrd.gz with the attached one. Then add 'ramboot=1' to the kernel line in your menu.1st or syslinux.cfg.
EDIT: I've added a shutdown script that saves your file back to disk. This is alpha software so please don't test with important data. You need to have enough room on your boot disk for 2 copies of your save file, as the script makes a backup of the old file before writing the new file to disk. The script assumes your boot drive has the same drive name as it did when you booted. This can be a problem with usb drives that have been removed and reinserted, so pay attention.
Edit: I've updated a new version of the initrd.gz to work with subdirectories.
Edit: 12/30/09 fix for shutdown script
Edit: 1/06/10 fix for copy2ram
The ramboot option enables you to load all of your sfs files and your save file into RAM and run completely diskless. Of course you need to keep these files small enough to fit in the amount of RAM you have, leaving some space for the OS to operate. You can then use the hdparm utility to shut down your hard drive (assuming you're running without a swap space) , saving power and reducing noise. Plus you'll get even faster performance. The downside is, none of your changes will be persistent (at least not yet, I may, in the future, provide a shutdown script that copies your save file back to disk). So the procedure is: set up your save file how you want it, then use the ramboot option when you're not planning on doing anything you'd want to save.
To try out ramboot, replace your initrd.gz with the attached one. Then add 'ramboot=1' to the kernel line in your menu.1st or syslinux.cfg.
EDIT: I've added a shutdown script that saves your file back to disk. This is alpha software so please don't test with important data. You need to have enough room on your boot disk for 2 copies of your save file, as the script makes a backup of the old file before writing the new file to disk. The script assumes your boot drive has the same drive name as it did when you booted. This can be a problem with usb drives that have been removed and reinserted, so pay attention.
Edit: I've updated a new version of the initrd.gz to work with subdirectories.
Edit: 12/30/09 fix for shutdown script
Edit: 1/06/10 fix for copy2ram
- Attachments
-
- rc.shutdown.gz
- (13.43 KiB) Downloaded 1091 times
Last edited by jemimah on Wed 06 Jan 2010, 17:13, edited 6 times in total.
nice
Excellent idea, since the available DDR2 sticks today have at least 1GB RAM storage.
If the user can tell where pup_save.2fs is located, s/he can copy it to hard disk (or other storage) before shutdown. But of course the shutdown script should be able to handle that, as you described.
EDIT: I booted initially without pup_save. At shutdown, it was trying to update a pup_saveOLDxx.2fs. Did you happen to hard-code your pup_save into the init script?
If the user can tell where pup_save.2fs is located, s/he can copy it to hard disk (or other storage) before shutdown. But of course the shutdown script should be able to handle that, as you described.
EDIT: I booted initially without pup_save. At shutdown, it was trying to update a pup_saveOLDxx.2fs. Did you happen to hard-code your pup_save into the init script?
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].
You can't copy it yourself because it's still mounted, and copying a mounted file system almost always causes severe corruption.
The script copies any file in your save directory that ends in *fs to RAM. If you want it to ignore a file, change the extension, or move it out of the directory with your SFS files.
It's supposed to throw an error message and die if you try to boot without a Pupsave. It must have found your old one and tried to use it. Nothing is hard coded, so I don't really know where it got that file from. It's also supposed to be forced into pupmode 12, so you really shouldn't see it spending a lot of time updating while you are shutting down.
The script copies any file in your save directory that ends in *fs to RAM. If you want it to ignore a file, change the extension, or move it out of the directory with your SFS files.
It's supposed to throw an error message and die if you try to boot without a Pupsave. It must have found your old one and tried to use it. Nothing is hard coded, so I don't really know where it got that file from. It's also supposed to be forced into pupmode 12, so you really shouldn't see it spending a lot of time updating while you are shutting down.
Thanks for the tip vg1. It appears my implementation is a bit different than what Pizzasgood did. So his shutdown script won't help me much.
This version does have dynamic RAM allocation, and it doesn't copy the files out of your 2fs file. It just copies the whole thing to RAM and mounts it from there. The trick will be to figure out how to unmount the RAM copy of your 2fs so you can copy it back to disk. You'll also need extra disk space to store a backup copy of your 2fs so you won't lose it if a power loss occurs during the copy-back process.
This version does have dynamic RAM allocation, and it doesn't copy the files out of your 2fs file. It just copies the whole thing to RAM and mounts it from there. The trick will be to figure out how to unmount the RAM copy of your 2fs so you can copy it back to disk. You'll also need extra disk space to store a backup copy of your 2fs so you won't lose it if a power loss occurs during the copy-back process.
aufs
"Logrow" idea is able to write back to mounted sfs:
http://aufs.sourceforge.net/logrow.txt
Kirk and Okajima seemed working on this. Kirk has Fatdog puplet here in the forum.
http://aufs.sourceforge.net/logrow.txt
Kirk and Okajima seemed working on this. Kirk has Fatdog puplet here in the forum.
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].
- prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
everything in RAM
I was away from Puppy for some time, so you regulars may be able to help me with this.
I remember a radical suggestion about a version without the layered file system. It would act like a full install to a ramdisk. This would certainly be fast and simple. Saving might require some more work. One thing I liked was the end of problems with "whiteout" files. Having files mysteriously revert to earlier versions when there are bugs in the layering would have driven me nuts, (if I hadn't already been there.)
For machines like the Eee-PC, where you can count on having 1 GB of RAM, this could be the way to go, when the whole OS takes about 100 MB. There are several different ways of putting "everything in RAM". Can someone outline the current alternatives?
I remember a radical suggestion about a version without the layered file system. It would act like a full install to a ramdisk. This would certainly be fast and simple. Saving might require some more work. One thing I liked was the end of problems with "whiteout" files. Having files mysteriously revert to earlier versions when there are bugs in the layering would have driven me nuts, (if I hadn't already been there.)
For machines like the Eee-PC, where you can count on having 1 GB of RAM, this could be the way to go, when the whole OS takes about 100 MB. There are several different ways of putting "everything in RAM". Can someone outline the current alternatives?
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
I wonder if there will be cross fertilisation with Quirky?load all of your sfs files and your save file into RAM and run completely diskless
http://puppylinux.org/wikka/Quirky
A couple of people have been working on using .sfs files without unioning themCan someone outline the current alternatives?
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
sfs? Are you sure? Maybe I don't quite understand, but it sounds to me like it would be for dynamically increasing the size of the .2fs file when you run out of space."Logrow" idea is able to write back to mounted sfs:
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
The simplest way to do a full install to ram is to dump your whole filesystem intro the initrd. I have done this successfully, but I abandoned the idea because the above way is superior. Boot time is very slow, because first you have to load your giant initrd to RAM and then you have to decompress it. So not only is it slow, but you need enough RAM to hold both the compressed and uncompressed initrd at the same time.
There's also this method: http://www.justlinux.com/forum/showthread.php?t=151619
However, using squash files is better because they don't need to be decompressed, so boot is fast, and a lot more data fits.
I've done some more research and as far as I can tell, it's actually impossible to unmount the root filesystem so you can unmount your save file cleanly. I suppose you could copy the individual files out, but it's painfully slow. I plan to experiment and see if copying the save file back to disk, while it's still mounted, but after all processes have been killed, results in any kind of corruption.
There's also this method: http://www.justlinux.com/forum/showthread.php?t=151619
However, using squash files is better because they don't need to be decompressed, so boot is fast, and a lot more data fits.
I've done some more research and as far as I can tell, it's actually impossible to unmount the root filesystem so you can unmount your save file cleanly. I suppose you could copy the individual files out, but it's painfully slow. I plan to experiment and see if copying the save file back to disk, while it's still mounted, but after all processes have been killed, results in any kind of corruption.
fatdog logrow
Here is rexterd's experiment with Fatdog and logrow:
http://www.puppy2.org/aufs/Fatdog112-logrow-aufs2.iso
The discussion of the aufs ideas by rexterd starts here and continues there..
http://www.puppy2.org/aufs/Fatdog112-logrow-aufs2.iso
The discussion of the aufs ideas by rexterd starts here and continues there..
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].
I looked into it, but didn't find much useful documentation. If anyone knows of any similar projects that do that successfully after starting the main OS, I'd love to take a look.
The shutdown script was more of an experiment than anything. I still recommend running without it, and saving important files to USB or mounting a hard drive to save files outside your 2fs file. Running totally in Ram and trusting that the shutdown script is going to work every time, makes me nervous.
The shutdown script was more of an experiment than anything. I still recommend running without it, and saving important files to USB or mounting a hard drive to save files outside your 2fs file. Running totally in Ram and trusting that the shutdown script is going to work every time, makes me nervous.
jemimah,
I've being yearning to try out RamBoot and finally got around to it and here's what happened.
Booted up with the new initrd and saved a minimal pupsave of 32m to a usb hard drive. Rebooted with ramboot=1 option and got this error..
"superblock could not be read.....try alternate superblock e2fsck -b 8193 <device> " (I later tried that with no success)
It then failed to mount pup-rw, loaded pup-431.sfs, layered,and then went to kernel panic
When booting without the ramboot=1 option, all goes as expected and the new pupsave file loads without a problem.
Any ideas as to what might be happening?
Thanks,
s
I've being yearning to try out RamBoot and finally got around to it and here's what happened.
Booted up with the new initrd and saved a minimal pupsave of 32m to a usb hard drive. Rebooted with ramboot=1 option and got this error..
"superblock could not be read.....try alternate superblock e2fsck -b 8193 <device> " (I later tried that with no success)
It then failed to mount pup-rw, loaded pup-431.sfs, layered,and then went to kernel panic
When booting without the ramboot=1 option, all goes as expected and the new pupsave file loads without a problem.
Any ideas as to what might be happening?
Thanks,
s
I've Got The Same Problem
Jemimah,
I thought it was just me. I have exactly the same problem. Machine is a P4, 2 gig Ram, Intel D865GBF Mobo, ATI x1650 video card. Puppy 4.3.1 frugal.
I've made a save file by booting from the RamBoot Initrd.gz but started with Pfix=Ram and then saved. Get exactly the same result when I boot with Ramboot=1. Also chokes on 2fs file made before trying RamBoot. Both will boot from the "normal" Initrd.gz.
In both cases I'm booting from the same Grub Menu.lst file, the only difference is editing before booting to add Pfix=Ram and eliminate Ramboot=1 when I created the 2fs save file to see if the original was somehow corrupted.
I thought it was just me. I have exactly the same problem. Machine is a P4, 2 gig Ram, Intel D865GBF Mobo, ATI x1650 video card. Puppy 4.3.1 frugal.
I've made a save file by booting from the RamBoot Initrd.gz but started with Pfix=Ram and then saved. Get exactly the same result when I boot with Ramboot=1. Also chokes on 2fs file made before trying RamBoot. Both will boot from the "normal" Initrd.gz.
In both cases I'm booting from the same Grub Menu.lst file, the only difference is editing before booting to add Pfix=Ram and eliminate Ramboot=1 when I created the 2fs save file to see if the original was somehow corrupted.
Jemimah,
Since the pupsave file works when the "ramboot=1" isn't used, perhaps it has something to do with the actual filesystem that the pupsave is on. My pupsave file is on an "ext3" filesystem.
Is there any ramboot load coding that might get confused in this case?
Thanks for any insights you may have,
s
(Mstar, I'm also happy it's not just me )
Since the pupsave file works when the "ramboot=1" isn't used, perhaps it has something to do with the actual filesystem that the pupsave is on. My pupsave file is on an "ext3" filesystem.
Is there any ramboot load coding that might get confused in this case?
Thanks for any insights you may have,
s
(Mstar, I'm also happy it's not just me )