Results 1 to 2 of 2

Thread: Run with ramdisk, update persistent store instead of ramdisk

  1. #1
    Senior Member registered user
    Join Date
    Sep 2006

    Run with ramdisk, update persistent store instead of ramdisk

    The traditional way of using persistent store has been to remaster seldom, if at all, and use a rather "large" (as compared to the sizes of short time changes) persistent store, typically 4 GB for FAT32 compatibility. I have usuallly done a couple (1-4) of remasterings of each Knoppix version, and the option of running with just ramdisk has been for special occasions only. I could use the ramdisk -> overlay technique, but I don't find it very useful for me.

    With Debian live and much more frequent squashfs remasterings, I have started to look at ramdisk use in another way. Right after a remastering, it won't make much difference whether you run with ramdisk or persistent store, and there may be a few advantages to decide only afterwards whether you want to keep the changes. Also. the need for space is rather limited, it is mostly for program installs and upgrades - almost all user space files (except for init/configuration stuff) are kept on volumes that are mounted the ordinary way.

    An alternative way of using persistent store/ramdisk could be to read the content of the persistent store into the ramdisk on startup, run from ramdisk and have the option to save to persistent store as needed, typically with a question about saving on shutdown. Most of the time, I would choose not to save.

    Reading from persistent store into the ramdisk takes some time, but with my use, typically below 1 GB used on persistent and SSD disks, it would take only a few seconds. And the machine would run faster.

    My total uncompressed system size is around 10 GB. That includes Oracle XE 11g and VMware workstation 10. With default squashfs compression, I have yet to approach the 4GB "limit", but the system is rather bloat-free.

  2. #2
    Senior Member registered user
    Join Date
    May 2006
    Columbia, Maryland USA
    Greetings, Capricorny.

    I think you might find MX-14 interesting even though it is
    currently a 32-bit Live system, it has built-in persistence
    and re-mastering capabilities. The author
    of the MX's init is BitJam, who gives Klaus K credit for inspiring it.
    With a fat32 base, it has a 4G filesize limit. Uses squashfs for
    saving compressed linuxfs, remasterings. Choice at boot on
    different persistence combinations.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts