How to keep the save file/folder small

[bigpup]

Settings, configurations, and anything actually installed, has to be in the save.
Stuff stored by web browsers, also go into the save.

Because save files are made a set size.
They have an issue of running out of space and have to be resized.

Not an issue with save folders. They self adjust, as long as there is some free space to use, where they are located.
But they can still get very big in size.

You can select to put stuff outside of the save.
Downloads, videos, images, documents, backup copies, a specific programs storage location, etc......

Good location is /mnt/home
It is outside of the save.
Actually, it is the top layer of the partition, the save file/folder is located.
you can even make different directories, in /mnt/home, to separate stuff into different locations or groupings.

Also, stuff located in /mnt/home can be accessed by other Puppy versions, you have frugally installed, on the same partition.

Example:
Partition with multiple different Puppy versions, each a different frugal install.
To any of them, when booted and operating the computer, this is /mnt/home
.

Screenshot(7).jpg (43.02 KiB) Viewed 1722 times

.
.

[xenial]

Thanks for the post.
I would like if possible to put my desktop configuration like wallpaper,icons etc out of the savefile..Not sure which files i need to moving and symlinking etc.

For every change i need to perform a save at the moment and i would rather there was a way of moving config out of save.

[geo_c]

Settings, configurations, and anything actually installed, has to be in the save.
Stuff stored by web browsers, also go into the save.

Also, stuff located in /mnt/home can be accessed by other Puppy versions, you have frugally installed, on the same partition.

Example:
Partition with multiple different Puppy versions, each a different frugal install.
To any of them, when booted and operating the computer, this is /mnt/home

In the past couple of months I began to symlink quite a lot of system files outside the pupsave folder, which might not work with a pupsave file on an NTFS file system. (I'm actually quite sure it won't.)

Here's a list of a few things that I store outside the save folder and symlink:

• Browser profiles (it would probably make sense to symlink the cache folders also)

• certain user-installed /root config folders

• user-installed /usr/share/themes gtk theme folders

• /usr/local/lib/X11/themes user-installed icon folders

• /root/my-applications/bin shell scripts that I'm likely to edit often

My custom icon set "UniChrome" is particularly large, and used in two different versions of Fossapup, one being a remaster. Storing it outside the pupsave with a symlink allows me to edit it and have the changes automatically reflected in both systems, as is the case with the other files in the list.

In the screenshot below the symlinks are the folders with the white and black arrows:

[bigpup]

Looks like geo_c needs to make a how to topic on what he is doing.
Give specific details on how to do it.
What geo_c is doing is totally different from a normally working Puppy frugal/save setup.
Not really sure what is actually still in the save if much.

I would look forward to having that how to.

This topic is more for new Puppy users and the basic ways to keep the save small.
Normally how the live or frugal install is setup and the save is used.

[geo_c]

Looks like geo_c needs to make a how to topic on what he is doing.

Not really sure what is actually still in the save if much.
I would look forward to having that how to.

This topic is more for new Puppy users and the basic ways to keep the save small.
Normally how the live or frugal install is setup and the save is used.

Yes, I will add a how-to-symlink-large-folders-and-config-files-shared-between-pupsaves topic. I can see that a new pup user without the proper puppy organization experience, could blow up the system apps pretty easily by attempting my method, which is inspired by @mikewalsh.

In reality, most of my system is in the pupsave, which for standard fossapup is currently between 1.5 and 2.0 GB. The only things I symlink are profile-folders/select-app-configs/theme-elements/personal-scripts that are added to the system, and which I don't want to manually keep in sync between different versions of fossapup, or on different computers. In other words, I don't want to copy a backup pupsave from one laptop to another in order to sync my system changes every single time I make a modification to something like my elinks color preferences, so I simply symlink the .elinks folder to a directory on the home drive. That directory I keep in sync with rsync on all of my computers. This way, many of the changes between computers like sound cards, wifi connections that are specific to that computer are NOT reset by unnecessarily moving a backup pupsave from one machine to the other, but my small changes in select applications are kept in sync through the symlinked folder on the home drive. The same goes for gtk themes, etc.

All of this can be discussed in the upcoming how-to-symlink-large-folders-and-config-files-shared-between-pupsaves thread.

[rockedge]

yes that would be really good.

I symlink applications and data from some central location across different Puppy's that all can use what is there. In principle this is easy to accomplish and very practical in some cases.

Working with Object detection/recognition involves training files or "weight data" files that are the results of training deep learning systems, are huge in size and very heavy. I work on the stuff in different Puppy's, KLV's, WDL's and "the Dogs" and the redundancy of keeping the same copies of these files would eat up lots of storage making small frugal installs humongous. Symlinking these works great.

When working on program code or the scripts and packages that make a KLV I jump around distros rapidly. Working on 12 copies of the same thing results in keeping these files synced is really really hard. I make a change, some time goes by and finding the one change again in 12 copies of the same thing.....you get the picture. Why GitHub and other version systems exist. So using one central copy to work on a symlink to reach it suffices in most cases.

It will be an very helpful thread and will display very well the advantages of working with Frugal installations and sharing uncompressed data.

[amethyst]

Just get rid of the savefile/folder altogether and save your stuff to an adrv/ydrv.

[bigpup]

You do know that the save file/folder, does not load into RAM, but only gets it's file system layered into the operating file system.

adrv and ydrv loads all of it's contents into RAM.

Maybe not an issue, if the adrv or ydrv are not that big.
But at what point do those get too big?

[wiak]

You do know that the save file/folder, does not load into RAM, but only gets it's file system layered into the operating file system

Is that also the case if Puppy booting from ntfs partition and using a savefile (savefolder being no good since symlinks wouldn't work)?

Was experimenting with similar matter only today and discussing it elsewhere (re: Puppy initrd/init though more generally from my point of view and similar but non-Puppy experiments).

Without having checked myself I would have though the savefile would be loaded read-only since ntfs partition it sits on would be loaded read-only by the initrd, unless, that is, the savefolder were first copied to RAM, and mounted read-write from there... which then uses lots of RAM? But could be some trick in Puppy - I wouldn't know since always use save folders and also always make my frugal installs onto Linux filesystems.

[bigpup]

As far as I know, unless something has gotten changed recently by code changes in Woof-CE.
The save works the same way no matter what format it is on.
The file system in the save is layered into the operating file system.
The save is always loaded read/write, but direct writing is controlled by pupmode, the Puppy OS is running in.
The pupmode the Puppy OS is running in, does control if the writes to the save, are a direct write, or first a write to a save ramdisk.
A save ramdisk is only used in pupmode 13 operation.
The save ramdisk starts out empty, until something gets done, that would require writing to the save.
Gets cleaned out, when a save update is selected, by clicking save icon on desktop, timed auto save, or shutdown.

A save folder can only be placed in a Linux format partition.
The save folder is reliant on using the Linux file system which is the Linux format.
A save file, is a Linux file system inside a file, so it can be placed on any format.

[amethyst]

You do know that the save file/folder, does not load into RAM, but only gets it's file system layered into the operating file system.

adrv and ydrv loads all of it's contents into RAM.

Maybe not an issue, if the adrv or ydrv are not that big.
But at what point do those get too big?

No, you are wrong. The contents of the base sfs and other drives are not loaded into RAM (the sfs files are just mounted). You need to distinguish between loading and copying to RAM in terms of how Puppy works. A small part of the system will load into RAM at bootup. The default behaviour of Puppy (if you have enough RAM) is that the base sfs and the other drive sfs's will also be COPIED to RAM (the sfs files are copied in its compressed format). This is a completely different issue. This copying can easily be negated by using the pfix=nocopy parameter. So no, if the pfix=nocopy parameter is used, nothing will be copied to RAM neither will the contents of the drives be loaded into RAM (apart from those files required to boot the system). To just mount the sfs's, uses very little RAM. The size of the sfs's does not matter when you use the nocopy parameter because nothing will be copied to RAM. The adrv and ydrv are basically just mounted like the base sfs but has preference to the other sfs files.

[bigpup]

Your method of running Puppy, seems to be something for you to give us a how to, on how to do it.

This topic is about the save file and how it operates in a normal boot.

nocopy is not a normal way to run Puppy.

If that is the way you boot Puppy, to limit RAM usage.
You are using the nocopy option, the way it was designed for.
But you are taking away one of the features of Puppy, having it already in RAM.
Operational speed.
Basically you have the complete OS acting like it is running from a save file/folder.

May not notice a big difference in speed with computer hardware now.
But go back to about 10 or 15 year old hardware with 5400 hard drives, DDR2 memory, and a lot slower interfaces.

That is why in the days when using Puppy from a CD install.
After it boots to a desktop.
The CD could be removed and the complete Puppy OS and programs, that are in it, are in RAM.
All those included programs can run.
And if the save is on some other drive. (which it usually was for a CD install boot)
It can be accessed for added stuff.
The CD drive is free to do something else.

[amethyst]

You are making too much of the nocopy issue. In my experience there is very little difference in operational speed and you may only notice it when you open a very big file for the first time during a session. If your RAM is limited, it is definitely not worthwhile to limit your RAM further by copying the sfs files to RAM (remember, the sfs files still need to be decompressed to access the files). More important for speed, is the compression method of your sfs's. All my sfs files are gz compressed, which makes it faster to decompress than xz compressed sfs's. Of course, if you have lots of RAM. you don't have to use the nocopy option in which case the sfs files (in the compressed state) will be copied to RAM by default (the copying to RAM at bootup will make the boot process longer). Also - as far as I know, the contents of your savefile is not loaded into RAM but at least the contents are in a an "uncompressed" state. An interesting test would be to compare the operational speed of a big application compressed as an adrv/ydrv copied to RAM at bootup and the same application installed and sitting in your savefile/folder (not in RAM). Again, any notable difference in speed may be observed when opening the application for the first time during a session because if you have lots of RAM the contents will be sitting in RAM anyway after first use of the application.

[bigpup]

This is getting off subject of this topic.
Time to start a new topic to discuss this stuff.

[geo_c]

Looks like geo_c needs to make a how to topic on what he is doing.
Give specific details on how to do it.

My method is detailed here: https://forum.puppylinux.com/viewtopic. ... 635#p65635