Puppy Linux Discussion Forum

By default if you install a (recent?) Puppy to a USB-Key using any Puppy-application it recognizes that the 'Storage' media is a flash-drive and writes the boot-menu/config argument 'pmedia=usbflash. When booted into the Puppy will be in PupMode 13: Default Save-to-media every 30 minutes, modifiable via System>Puppy Event Manager to any time interval including 0/zero=never with 'Ask at Shutdown'.
When the media is a hard-drive, however, the written boot-menu/config argument is 'pmedia=atahd'. When booted into the Puppy will be in PupMode 12: Default Save-to-media every 30 minutes. And while the time interval is modifying, while in PupMode 12 the automatic 'Save-at-shutdown/reboot' can not be turned off.
Well it can, but that requires manually editing the boot menu/config argument to add/change to read 'pmedia=ataflash'.
Why isn't 'pmedia=ataflash' the default argument being written? Is there some significant advantage obtained by employing PupMode 12 rather than PupMode 13?

The idea behind the pupmodes is different operation for different drives and how they are affected by writes.
USB, SSD, SD cards have number of writes limit, before they are suppose to start going bad.
So, idea is to limit how often a write is done.

To be honest, the drives now have such a high write limit, that they are about the same as what a hard drive has.
Name brand ones anyway do.

Puppy, installed to a hard drive, does not need to limit how many times you write to the hard drive.
Pupmode 12, the save is a direct write to hard drive.
Anytime something needs to go into the save, it does it directly, at that time.
So, save is constantly being updated.
The Update at shutdown, is just to do one final check, to make sure all is in the save. That should be quick to do.

In pupmode 12, non of those save options in the Puppy Event Manager, should be active. Should be grayed out.

Pupmode 12 does not need a saveramdisk using up some of the RAM.

Pupmode 13 uses a saveramdisk to store changes to the save, before they get written to the save.
the saveramdisk is emptied, when save icon is clicked or timed save activates or shutdown save operation.
save options, in the Puppy Event Manager, will be active, giving you choices on how this will work.

Good question. If JWM had this X-series option:

and -0 in the Puppy Event Manager:

problem solved.

Did @rg66 create them himself?

mikeslr wrote: Mon May 10, 2021 11:25 pm

When booted into the Puppy will be in PupMode 13: Default Save-to-media every 30 minutes, modifiable via System>Puppy Event Manager to any time interval including 0/zero=never with 'Ask at Shutdown'.

When the media is a hard-drive, however, the written boot-menu/config argument is 'pmedia=atahd'. When booted into the Puppy will be in PupMode 12: Default Save-to-media every 30 minutes. And while the time interval is modifying, while in PupMode 12 the automatic 'Save-at-shutdown/reboot' can not be turned off.

Well it can, but that requires manually editing the boot menu/config argument to add/change to read 'pmedia=ataflash'.

Why isn't 'pmedia=ataflash' the default argument being written? Is there some significant advantage obtained by employing PupMode 12 rather than PupMode 13?

As amethyst points out, viewtopic.php?p=25113#p25113:
"The /initrd/pup_..'s are the Puppy mounting layers in order of preference. For frugal installs:
/initrd/pup_rw = Top savings layer (contents change during a session).
/initrd/pup_ro1 = Existing savefile if you are using a usb drive (pupmode 13). This layer is not used when you have an internal HD install (in the latter case your existing savefile will be mounted as /initrd/pup_rw)"
but I would add that if you write the boot-argument 'pmedia=ataflash' you force Puppy to operate as pupmode 13 even when you have an Internal HD frugal install.

Both pup_rw and pup_ro1 occupy Random Access Memory. So pupmode 12 does not offer any advantage in how much available RAM remains during heavy RAM-demanding activity, except perhaps to the extent that periodically writing the contents of RAM to the storage media may flush RAM. I'm not sure it does; and there are better ways to clear RAM than permanently preserving the then current contents of RAM. Automatically preserving the current contents of RAM means that every mistake you've made, every broken or otherwise non-functional application and all the junk (perhaps malware) you've inadvertently and unknowingly acquired while surfing the web are preserved if they then happen to be in RAM.
Puppy Event Manager can be easily configured so that Puppys operating under the boot-menu argument pmedia=usbflash or ataflash will periodically and/or at shutdown Save to Media (the effect of pupmode 12). But it can't change the effect of pupmode 12 to that of pupmode 13.

So I'll ask again, what advantage is served by pupmode 12; and, raise my real concern:
What advantage is served by having the applications which create grub4dos's menu.lst and grub2's grub.cfg write arguments which have frugal Puppys installed to a Hard Drive operate under pupmode 12 rather than pupmode 13.

Both pup_rw and pup_ro1 occupy Random Access Memory

If there is pup_rw and pup_ro1, then usually:

pup_ro1 is a save file or save folder, mounted rw.
Nothing in pup_ro1 is copied to ram.
(you can mount a 4TiB file system. You don't need 4TiB of ram to mount 4RiB file system.

pup_rw is a tmpfs file system, created in ram. It uses only as much ram that is needed to hold whatever is put into it.
pup_rw DOES occupy ram. pup_ro1 does not.

Basically, whatever is in pup_rw (the top layer) gets copied to pup_ro1 (the 2nd layer) if you click the save button.

Normally, pup_rw is a file system on the hard drive, (the save file or folder), directly mounted. (mounting the save file/folder does not copy anything to ram.)
Normally, the Puppy sfs files, including the xdrv, fdrv, ydrv, and ardv sfs files get copied to ram. Then they are mounted, and used to make the aufs layered file system. They are found and copied to ram by code (instructions) in the Puppy initrd.gz. This is not the same thing as mounting. When you mount a file system, nothing is copied to ram. When Puppy boots, instructions in the initrd.gz copy the sfs files to ram. That is so you can eject the cd/dvd and use the cd/dvd optical drive or the usb flash drive. pfix=nocopy can be used. The sfs files will not be copied to ram, which will save about 500MiB of space in ram, but you can not eject the cd or unplug the usb drive, if that is where the sfs files are. Access to the sfs fike systems would be a lot slower. The sfs files can be copied to the hard drive, which would make access to the sfs file systems faster than being on a cd or usb drive.

Thr main advantage to copying the sfs files to ram is you can use the cd/dvd optical drive and usb port. And it will be faster. The main disadvantage is it uses about 500MiB of ram.

The main advantage of having a ram layer to read/write to when the save file/folder is on a usb drive, is that it helps to make a usb drive last longer, because there are fewer writes. It also is much faster. Also, it can be configured to write to the save file only when you click the button.

My post was about going around it, if some case for Pupmode 12 can be made, and if the pmedia= change is not a priority.

It seems normal for us to have to edit automatically generated boot menus.

JASpup wrote: Thu May 13, 2021 4:05 am

My post was about going around it, if some case for Pupmode 12 can be made, and if the pmedia= change is not a priority.

It seems normal for us to have to edit automatically generated boot menus.

I think the saving wear to the disk stuff is irrelevant now.

The case for pupmode 12 is that everything is saved to the hard drive in real time. If the electricity goes out or you crash for some reason, you don't lose your work.

The advantage to 13 is that you control when changes are saved, so if you install an app that blows up your system you just reboot without saving and everything is fine.

Depends on what you would call an advantage.

Puppy originally, worked in pupmode 12, after making a save and booting, using it.
The save is write active all the time.
You do something that needs to be put in the save and it is directly written to the save.

When Puppy started being put on USB, SD cards, etc...., drives that have number of write limits, (that was a low amount).
Pupmode 13 was developed.
The save is not write active, but a save ramdisk is.
The save ramdisk is a section of memory set aside to act as the save write location.
At some point the ramdisk is emptied into the actual save.
This cuts down on number of times the save is actually written to.
Thus, it should make the drive last longer.
Also, how you want this pupmode 13 save activity to work, had options added to the Puppy Event Manager->Save session

dancytron wrote: Thu May 13, 2021 5:29 am

I think the saving wear to the disk stuff is irrelevant now.

The case for pupmode 12 is that everything is saved to the hard drive in real time. If the electricity goes out or you crash for some reason, you don't lose your work.

The advantage to 13 is that you control when changes are saved, so if you install an app that blows up your system you just reboot without saving and everything is fine.

That's a good case for 12, but for it, it should not matter whether USB or internal. Frugal is frugal.

Wear might matter a little bit if you don't want to start over on USBFLASH, but that probably has more to do with the quality of the media.

The sum is, I wouldn't make the choice on the media you choose, assuming real time saving is better.

There seems different options for this, like the journaled file system option we're presented when creating a save.

I just happen to boot USB, but if I didn't I would want to modify the system to work this way.

To me, the usb vs internal distinction is just historical. You can set it however you want. I use pupmode 13 just save manually and ask on exit, but if I am setting it up for someone else to use it, I use pupmode 12 so they don't mess up and lose stuff and blame me.

On Debian dog its just "save on exit" for mode 13 and something similar for fatdog.

Very useful explanation. Is it possible to load SFS into Puppy system directories or even install packages and have them not loaded into ram? The only way I can think of doing this is manually with symlinks.

The nocopy option appears all-or-nothing.

williams2 wrote: Thu May 13, 2021 1:59 am

If there is pup_rw and pup_ro1, then usually:

pup_ro1 is a save file or save folder, mounted rw.
Nothing in pup_ro1 is copied to ram.
(you can mount a 4TiB file system. You don't need 4TiB of ram to mount 4RiB file system.

pup_rw is a tmpfs file system, created in ram. It uses only as much ram that is needed to hold whatever is put into it.
pup_rw DOES occupy ram. pup_ro1 does not.

Basically, whatever is in pup_rw (the top layer) gets copied to pup_ro1 (the 2nd layer) if you click the save button.

Normally, pup_rw is a file system on the hard drive, (the save file or folder), directly mounted. (mounting the save file/folder does not copy anything to ram.)
Normally, the Puppy sfs files, including the xdrv, fdrv, ydrv, and ardv sfs files get copied to ram. Then they are mounted, and used to make the aufs layered file system. They are found and copied to ram by code (instructions) in the Puppy initrd.gz. This is not the same thing as mounting. When you mount a file system, nothing is copied to ram. When Puppy boots, instructions in the initrd.gz copy the sfs files to ram. That is so you can eject the cd/dvd and use the cd/dvd optical drive or the usb flash drive. pfix=nocopy can be used. The sfs files will not be copied to ram, which will save about 500MiB of space in ram, but you can not eject the cd or unplug the usb drive, if that is where the sfs files are. Access to the sfs fike systems would be a lot slower. The sfs files can be copied to the hard drive, which would make access to the sfs file systems faster than being on a cd or usb drive.

Thr main advantage to copying the sfs files to ram is you can use the cd/dvd optical drive and usb port. And it will be faster. The main disadvantage is it uses about 500MiB of ram.

The main advantage of having a ram layer to read/write to when the save file/folder is on a usb drive, is that it helps to make a usb drive last longer, because there are fewer writes. It also is much faster. Also, it can be configured to write to the save file only when you click the button.

Both JASPup and dancytron make valid arguments. But why isn't the default configuration for a Frugal on a Hard-drive:

Pupmode 13 with SaveSession Interval set to every 30 minutes.

In usage that provides the equivalent of Pupmode 12. Newbies don't have to be reminded to periodically Save. But a Newbie reaching the 'tenderfoot' stage can easily call upon Puppy Event Manager's GUI to change that interval.
With pupmode 12 as the default It takes an entirely higher level of self-confidence and knowledge before someone accustomed to Window's hand-holding to perform the above AND also:
Open menu.lst/grub.cfg in your text editor and edit/add "pmedia=" so that it reads "pmedia=ataflash".

Perhaps I'll answer my own question: See the complications which arise when Puppys are forced into pupmode 13, with Puppy Event Manager's Save Interval set to "0/zero", "Ask at shutdown", viewtopic.php?p=2235#p2235. But that's not the case if the default Save Session interval is 30.

See the complications which arise when Puppys are forced into pupmode 13, with Puppy Event Manager's Save Interval set to "0/zero", "Ask at shutdown"

I just change the time-interval there to something like 5 seconds (edit that particular line in the shutdown config file). Puppy reboots/shutdown without saving by default when the time runs out.

JASPup: Is it possible to load SFS into Puppy system directories or even install packages and have them not loaded into ram?

Not sure I understand the question.

The Puppy OS sfs files are automatically copied to a tmpfs in ram, then they are mounted and become layers in the aufs file system.
Unless pfix=nocopy which saves some space in ram, about 500 or 600 MiB, but ties Puppy to whatever drive that the sfs are on.

# ls -goh /initrd/mnt/tmpfs/*sfs
-rwxrwxrwx 1 114M Mar  9 01:29 /initrd/mnt/tmpfs/adrv_bionicpup64_8.0.sfs
-rwxrwxrwx 1 279M Apr 26  2019 /initrd/mnt/tmpfs/puppy_bionicpup64_8.0.sfs
-rwxrwxrwx 1  57M Apr 26  2019 /initrd/mnt/tmpfs/zdrv_bionicpup64_8.0.sfs
#

Other sfs files, like firefox.sfs, avidemux.sfs, libre-office.sfs etc etc are not automatically copied to ram before mounting. Usually these sfs files are located in /mnt/home/

Install packages (pets, debs, rpms, etc etc) are installed to the save file/folder. If you are running "live", with no save file/folder, then packages will be installed in the tmpfs file system in ram. Same for mode 13, but the files installed to the tmpfs will eventually get copied from the save space in ram to the save space in the save file. Or not.

Mounting a file system that is in a block device does not automatically copy files that are in that file system to ram.
That is, mounting a file system does not use any space in ram.
(a small amount of space is used for buffers and linking to the Linux VFS (Virtual file System))

williams2 wrote: Thu May 13, 2021 7:40 pm

JASPup: Is it possible to load SFS into Puppy system directories or even install packages and have them not loaded into ram?

Not sure I understand the question.

The question was posed from the perspective of after boot decisions are made, yet still for the motive of sparing ram usage.

A modern browser is a good example, or the mammoth Libreoffice I recently ran SFS on my 64 machine.

Programs operating in ram, loading their files there, seems to have limited need beyond speed and wear-and-tear -- great for the os, skeptical for, say, browsers when clearly after the browser is opened (which can take a while from ram anyway), the performance bottleneck is not the storage medium.

I imagine what I'd have to do to achieve my question implication is put anything I don't want in ram in a pupsave, the only frugal layer that isn't in ram, or keep apps standalone if possible.

I am using Firefox 88.0.1 On BionicPup64 8.0.

I do not have Firefox installed at all.

My firefox-start script deletes all the application's files, all the config files, and all the cache files, if any.
The it unzips the app files and the config files, so that every time Firefox starts, it is clean, and pristine, starting exactly the same way each time it starts, from the tar.gz files that I explicitly saved, the way I wanted it.

It runs completely in ram, the app files and the config files, and the files in cache. It does seem to run noticeably faster than from an sfs file. It does take a little longer to start, because about 250MiB of files get unzipped into ram.

Archwiki - Firefox/Profile on RAM https://wiki.archlinux.org/title/Firefox_on_RAM

Normally, in Puppy, sfs files do not use any space in ram.
The Puppy operating system files ARE copied to ram, by default, but sfs files that are loaded, like libreoffice.sfs, etc, are not copied to ram.
Pets that are installed, normally install to the save file/folder. The save file is not ram.

sfs files do not use space in ram.
Pets do not use space in ram.

The Puppy OS sfs files will not be copied to ram if the pfix=nocopy boot option is used. It would save about 500MiB of space in ram.

# ll /initrd/mnt/tmpfs/*sfs
-rwxrwxrwx 1 114M Mar  9 01:29 /initrd/mnt/tmpfs/adrv_bionicpup64_8.0.sfs
-rwxrwxrwx 1 279M Apr 26  2019 /initrd/mnt/tmpfs/puppy_bionicpup64_8.0.sfs
-rwxrwxrwx 1  57M Apr 26  2019 /initrd/mnt/tmpfs/zdrv_bionicpup64_8.0.sfs
#

williams2 wrote: Sat May 15, 2021 3:26 am

It runs completely in ram, the app files and the config files, and the files in cache. It does seem to run noticeably faster than from an sfs file. It does take a little longer to start, because about 250MiB of files get unzipped into ram.

Archwiki - Firefox/Profile on RAM https://wiki.archlinux.org/title/Firefox_on_RAM

At your skill level it wouldn't be worth your time to use a computer where 250M worth of ram is damaging.

On my 64 machine I just want to understand Puppy allocation, because if I'm wasteful I might as well be using another distro or Windows. I do like MATE, but that is an indulgence.

In 2G 32-bit I may be wanting all three out of ram. There's esoteric ram usage I'm challenged to keep track of, now using the -c switch in du for tmpfs. CPU is a bigger strain. It's easier to make the balance when you know what's happening behind the scenes and how to control it.

The slower machine is the one I prefer to type on.

williams2 wrote: Sat May 15, 2021 3:26 am

Normally, in Puppy, sfs files do not use any space in ram.
The Puppy operating system files ARE copied to ram, by default, but sfs files that are loaded, like libreoffice.sfs, etc, are not copied to ram.
Pets that are installed, normally install to the save file/folder. The save file is not ram.

sfs files do not use space in ram.
Pets do not use space in ram.

The NOCOPY I get, but SFS I do not. SFS are simply mounted layers sourced in the loaded SFS that 'appear' to become a part of the system file structure but actually are just a single file that is read to run an application?

That would make them roughly equally appealling as pupsaves.

I'm still interested to understand why SFS Load likes SFS files in /mnt/home, why it's of consequence.

If you install a .pet that isn't saved to pupsave, where else can it be but ram?

JASpup wrote: Sat May 15, 2021 4:12 am

williams2 wrote: Sat May 15, 2021 3:26 am

Normally, in Puppy, sfs files do not use any space in ram.
The Puppy operating system files ARE copied to ram, by default, but sfs files that are loaded, like libreoffice.sfs, etc, are not copied to ram.
Pets that are installed, normally install to the save file/folder. The save file is not ram.

sfs files do not use space in ram.
Pets do not use space in ram.

The NOCOPY I get, but SFS I do not. SFS are simply mounted layers sourced in the loaded SFS that 'appear' to become a part of the system file structure but actually are just a single file that is read to run an application?

That would make them roughly equally appealling as pupsaves.

I'm still interested to understand why SFS Load likes SFS files in /mnt/home, why it's of consequence.

If you install a .pet that isn't saved to pupsave, where else can it be but ram?

Extra sfs's do actually use some space in RAM in the loading process. I think it's around 10MB. This is just an observation I've made some time ago, could be wrong.

amethyst wrote: Sat May 15, 2021 5:20 am

Extra sfs's do actually use some space in RAM in the loading process. I think it's around 10MB. This is just an observation I've made some time ago, could be wrong.

10MB as a percentage of?? If that's the case we should know where it is, have some Conky add-on (or Task Manager in my case).

SFS seem and feel like ram. The only alternative I can think of is loading a file, like a virtual disk.

Extra sfs's do actually use some space in RAM in the loading process. I think it's around 10MB. This is just an observation I've made some time ago, could be wrong.

You're not wrong, mounting the file system on a block device creates a buffer, which uses a small amount of space in ram. and linking the file system of the mounted device to the Linux Virtual File System requires a small amount of space.

I was trying to be extremely clear, trying to avoid confusion. Normally, for all practical purposes, all things being equal ...

As the FS is used, the amount of space in ram used by the buffer tends to change. For example:

# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        554M        479M        897M        770M        1.7G        1.5G
Swap:            0B          0B          0B
# echo 3 > /proc/sys/vm/drop_caches
cache cleared
# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        481M        2.0G        897M        1.7M        995M        1.9G
S

Running BionicPup64, clearing the cache, the space used by buffers went from 770MB to 1.7MB

So what.

Buffers are used to make the memory work better and program operations to function better.
Memory is there to use.
Use it!

If something more important needs the memory space, it will be released from the buffer area of ram.
You need to read up on what buffers are all about in Linux.

Example my 4GB memory usage at this exact point of time:
Actual Used RAM: 359 MB Used - (buffers + cached)
Actual Free RAM: 3435 MB Free + (buffers + cached)

The Linux kernel has an affect on exactly how memory is controlled.
Memory control has changed in the development of the kernel.

You can not just make specific statements about Puppy and how it works.
The Puppy version has a big affect on exactly how it works.
This stuff has changed over the years.
Control of processes have changed, as the Linux kernel changes.
Core programs have changed over the years.

Specific version of Puppy matters.

Specific kernel being used matters.
Specific config settings for the kernel can affect everything.
This config is up to who compiled the kernel and how they wanted to setup the config settings.

General operation statements, are still true, for all versions of official Puppy.
They use SFS files
They load stuff into memory.
They use a save file/folder.
They use a save ramdisk, depending on the pupmode of operation.
They can be installed as a frugal install, on any drive partition, formatted in any format.
Etc..........

There is sometimes confusion about mounting sfs file systems.

Mounting sfs file systems, in Puppy, or any Linux distro, does not automatically copy huge amounts of data to ram.

I can see where the confusion comes from.

When Puppy boots, normally, typically, there are instructions in the initrd to find the Puppy OS sfs files and copy them to ram, then mount them, then add them as layers to the aufs file system. So a person might think that mounting an sfs file always automatically copies the sfs file to ram. That assumption is not correct.

williams2 wrote: Thu May 13, 2021 7:40 pm

...
That is, mounting a file system does not use any space in ram.
(a small amount of space is used for buffers and linking to the Linux VFS (Virtual file System))

Relevant hardware consists of Random Access Memory, Central Processing Unit(s) and Storage Medium. Before boot-up a Puppy's system files --containing the information which will be used-- including any SaveFile/Folder-- occupy space on a Storage Medium. On boot-up, the operating system --the information in use-- is in RAM. Consistent with the above quote, my exploration of 'stripping Puppys' and of using chrooted Operating Systems and containers suggest these have little impact on the amount of 'Actual Used RAM' by the operating system as reported by Pup-SysInfo.

Using neither 'pfix=copy' nor 'pfix=no-copy', Pup-SysInfo report on my current computer's RAM usage:

Memory Allocation:
Total RAM: 15904 MB
Used RAM: 1865 MB
Free RAM: 14039 MB
Buffers: 120 MB
Cached: 1351 MB
Total Swap: 0 MB
Free Swap: 0 MB

Actual Used RAM: 394 MB Used - (buffers + cached)

Where is the 120 Mbs of Buffered 'files' and the 1351 Mbs of Cached 'files' physically located? Or isn't it physically anywhere? And, if cached and buffered 'files' are not actually occupying RAM what is the mechanism used to provide the information contained in the files on the storage medium to the operating system in RAM? What is the significance of the above reported "Used RAM: 1865 MB"? What is the Pup-SysInfo actually telling about RAM usage?

A system has to obtain the information it uses from somewhere. If you boot a Puppy and remove the storage media it booted from and it still fully functions, where is the information enabling it to do so? If it's been 'cached', where is that 'cache'? If its compressed then cached-in-RAM what algorithm enables 1865 MB of information to be compressed into almost no space [the RAM difference between booting with and without the 'no-copy' argument]?

By the way, this thread has meandered beyond both its stated subject --whether PupMode 12 has some advantage-- and its later revealed concern --why is the default 'menu-list' generated for a Puppy booted from a hard-drive such that it operates under PupMode 12 rather than 13.

Actually, don't answer the above questions on this thread. I'll open another thread after locating a Puppy on a USB-Key with two variants/folders. One folder will be the Bionic64 bit (used to generate the Pup-SysInfo) report just copied from my hard-drive. The second will have converted its SaveFile to a ydrv.sfs. The 2nd supposedly should be fully functional even after unplugging the USB-Key. What effects will pfix=copy; pfix=no-copy have? Will there be a difference in RAM usage between the two variant setups?
Better yet. Don't wait for me. Run your own experiment and open a thread to post your findings.

By the way, this thread has meandered beyond both its stated subject

Yes, threads can easily meander off-course.

My posts in this thread have been an attempt to answer certain specific questions, in particular, questions that show a certain amount of confusion.

Where is the 120 Mbs of Buffered 'files' and the 1351 Mbs of Cached 'files' physically located?

The 120M of space for buffers is in ram. Physically, the ram chips on the motherboard. The 1361M of space for the cache is also space used in ram.

Strictly speaking, the buffers and cache space do not contain "files". Data from the block device that contains the file system is copied block by block from the device to the buffer space in ram. As data is copied to and from the buffer space, the blocks of data are also copied to the cache space, just in case it might be used again a little later.

The number of bytes used by the cache includes space used by the tmpfs file system (/tmp and the pup_rw top aufs layer if running in mode 5 or mode 13). So the space used by cache is temporary copies of the blocks in the buffers, and the blocks of data that make up the tmpfs file system. Clearing the cache will not delete the files in /tmp and in pup_rw.

what is the mechanism used to provide the information contained in the files on the storage medium to the operating system in RAM?

A file system contains the data that is the contents of each file, but a FS also contains meta data, for example, the file sizes, the paths in the file system, permissions, block allocatin data, etc. The file system drivers understand how the file system works, and can understand what the blocks of data in the buffers and in cache mean.

What is the significance of the above reported "Used RAM: 1865 MB"?

What exactly is reported by various program, for example, free, depends on that program. Different programs have different names and each program calculates values like memory free, and memory available etc, etc. I think it's often best to (as bigpup suggests) allow the kernel to do it's job, and automatically handle the ram. It usually does a fairly good job.

What is the Pup-SysInfo actually telling about RAM usage?

Each program show information about memory usage in it's own way. The programs are reporting memory use based on data from the kernel:
cat /proc/meminfo
Most of what the kernel is doing is automatic, and it can be difficult to interpret the data.
In your case, you have Total RAM: 15904 MB 16GiB of ram, which should be plenty of ram for most applications in the Puppy OS.

What is the significance of the above reported "Used RAM: 1865 MB"?

In this case, it is ram used by programs, drivers, etc + buffer space used + cache space used.
The cache space includes space that is being used by files in the tmpfs (including files in /tmp)

The "Actual Ram Used" is "Used RAM" - buffers - cached
Each program reporting memory usage does it it's own way.
Most of the time, you can follow bigpup's advice and just let the kernel do it's job.

Actually, don't answer the above questions on this thread.

Whoops, too late.

Save file or ydrv.sfs shouldn't make any real difference.
copy should use about 500MB more than nocopy.

A little demonstration:

creating a 15GiB file each byte being a zero (15 billion zero bytes)
dd if=/dev/zero of=zero.bin bs=1M count=15360

making a squash fs containing a 15G file:
mksquashfs 000tmp/ zero.sfs

# ll 000tmp/bin/zero.bin zero.sfs 
-rwxr-xr-x 1  15G May 15 23:32 000tmp/bin/zero.bin
-rwxr-xr-x 1 8.0K May 15 23:38 zero.sfs

free before and after mounting the zero.sfs file:

# cache-clear 
cache cleared
# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        162M        2.4G        824M        1.7M        904M        2.3G
Swap:            0B          0B          0B
# 
# mount-FULL -o loop /mnt/home/zero.sfs /mnt/tmp/
# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        163M        2.4G        824M        5.7M        908M        2.2G
Swap:            0B          0B          0B
# cache-clear 
cache cleared
# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        163M        2.4G        824M        1.7M        904M        2.3G
Swap:            0B          0B          0B
# 

free before and after unmounting zero.sfs:

# du -ah /mnt/tmp/
15G	/mnt/tmp/bin/zero.bin
15G	/mnt/tmp/bin
15G	/mnt/tmp/
# 
# umount-FULL /mnt/tmp/
# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        172M        2.4G        824M         10M        912M        2.2G
Swap:            0B          0B          0B
# cache-clear 
cache cleared
# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        172M        2.4G        824M        1.8M        904M        2.2G
Swap:            0B          0B          0B
# 

rename zero.sfs to ydrv so it will automatically be copied to ram and mounted as an aufs layer:

# cd /mnt/home/
# mv -i zero.sfs ydrv_bionicpup64_8.0.sfs
# wmreboot

free ram with 15G ydrv.sfs automatically copied to ram and mounted:

# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        124M        2.5G        472M        103M        807M        2.5G
Swap:            0B          0B          0B
# cache-clear 
cache cleared
# free -wh
              total        used        free      shared     buffers       cache   available
Mem:           3.5G        121M        2.8G        472M        2.1M        541M        2.6G
Swap:            0B          0B          0B
# 
# aufs-layers 
/initrd/mnt/tmpfs/pup_rw=rw
/initrd/pup_a=rr
/initrd/pup_y=rr
/initrd/pup_ro2=rr
/initrd/pup_z=rr
# 
# ll /bin/zero.bin 
-rwxr-xr-x 1 15G May 15 23:32 /bin/zero.bin
# 

# 
# cd /mnt/home/
# mv -i ydrv_bionicpup64_8.0.sfs zero.bin
# 
# ll /initrd/mnt/tmpfs/
total 450M
-rwxrwxrwx  1 114M Mar  9 01:29 adrv_bionicpup64_8.0.sfs
-rwxrwxrwx  1 279M Apr 26  2019 puppy_bionicpup64_8.0.sfs
drwxr-xr-x 13  300 May 15 23:58 pup_rw
drwxrwxrwt 13  540 May 15 23:58 tmp
-rwxrwxrwx  1 8.0K May 15 23:38 ydrv_bionicpup64_8.0.sfs
-rwxrwxrwx  1  57M Apr 26  2019 zdrv_bionicpup64_8.0.sfs
# 
# rm 000tmp/bin/zero.bin 
# rmdir 000tmp/bin/
#

bigpup wrote: Sat May 15, 2021 7:47 pm

Buffers are used to make the memory work better and program operations to function better.
Memory is there to use.
Use it!

I empathize with that stance. Understanding is required to make performance and use compromises, and assuming 'the system' is going to do what's best is folly.

We can transpose the value onto life: I went to a baby shower a few years back where they threw away enough food for an entire preschool lunch, but better quality.

I didn't want to seem greedy taking leftovers, but a modest portion would do me for a week.

The parents are good; it's just an issue of conscience. I still think about it.

I wouldn't have done it, and I don't think Barry would either. We would have bought less food or made a priority of not wasting it.

I could junk this paperweight laptop for one with a market value, but it's useful if I'm cognizant of ram usage.

Please excuse if pedantic:

The difference is system SFS are both copied into ram and mounted there, and others are just mounted (which would be why Puppy wants them secure in /mnt/home)?

If ram conservation is a goal then alphabet drives aren't a solution for any user apps, they should be in SFS or standalone.

How a .pet is also mounted (not in ram) is something I still need to comprehend. The file system appendage by loading or installing has to be just a reference to its source to not be in ram. When you're using the ppm, the installation files it downloads must remain on your system for them not to go to ram.

williams2 wrote: Sat May 15, 2021 8:43 pm

Mounting sfs file systems, in Puppy, or any Linux distro, does not automatically copy huge amounts of data to ram.

I can see where the confusion comes from.

When Puppy boots, normally, typically, there are instructions in the initrd to find the Puppy OS sfs files and copy them to ram, then mount them, then add them as layers to the aufs file system. So a person might think that mounting an sfs file always automatically copies the sfs file to ram. That assumption is not correct.