Does PupMode 12 have any advantage over PupMode 13?

[williams2]

/mnt/home/ is just a convenient place.. /mnt/home/ is usually automatically mounted by Puppy. The save file is often in /mnt/home/ or in a sub dir.

If ram conservation is a goal then alphabet drives aren't a solution

pfix=nocopy will use about the same space in ram as a "full install"
With pfix=nocopy the Puppy OS sfs files are not copied to ram.

Mounting a file system does not use any significant space in ram.

How a .pet is also mounted (not in ram) is something I still need to comprehend.

A .pet file is a .tar.gz or a .tar.xz file. Rename the file if you want it to be treated as a .tar.gz file.

Code: Select all

# file opera-11.64-1403.x86_64_2.pet
opera-11.64-1403.x86_64_2.pet: XZ compressed data
#

If you unzip a .pet file to / the files unzip to the correct paths.

If you use a save file, when unzipping the pet (tar) file to the file system, the changes end up in the save file.

If you are running without a save file (pfix=ram), the changes end up in the ram layer at the top of the aufs stack.

[amethyst]

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.

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.

There's a difference between mounting and copying to RAM. The mere mounting/loading of an sfs takes very little memory (about 10MB) as previously mentioned. The adrv and ydrv are copied to RAM automatically at bootup but you can bypass this automatic behaviour with the pfix=nocopy parameter. Note that when the adrv/ydrv is copied to RAM, the sfs is copied as is in its compressed state. So it depends on the size of your sfs which mount will be used for the copy operation (if your adrv/ydrv is 20MB, 20MB will be copied). Extra sfs loaded during a session are not automatically copied to RAM. The sfs_load application will typically ask you if you want to copy it to RAM if it is not located at /mnt/home or located at the same location as your Puppy files. Pets are not mounted or loaded but installed to the filesystem. The pet installation will reside in RAM until it's saved to the savefile/folder. The time it resides in memory depends on your setup. If you are running in pupmode 12 (savefile/folder on harddrive), the saving to savefile is almost immedeiately whilst in pupmode 13 the saving will be done according to your save time setting.

[JASpup]

Mounting a file system does not use any significant space in ram.

O-kay. My question was less about mounting implications than if indeed mounting uncopied (to ram) .pet and .sfs is what's actually happening, and it appears you're stating yes. Practical then for a user are limits to what one should mount.

SFS Load will duplicate any SFS you wish to load if it's not in /mnt/home. You have to instruct it not to.

I should have added to my last post: sfs, standalone, or pupsave.

If ram is my bottleneck, I want to be able to see it. Then you might ask these gritty questions like: if ram constrained, don't copy the system, or use a swap file?

Fundamentally I have Task Manager running 80% of the time, and I suspect it presents a distorted (under accounted) sense of ram usage.

[amethyst]

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

ALL additional drives like adrv, ydrv are normal sfs files as mentioned before. They are named adrv, etc. for a specific reason, ie. that the init script loads them automatically at bootup to a specific layer. If you boot with pfix=nocopy, the RAM usage in terms of mere loading the sfs (adrv or whatever other extra sfs file) is basic neglectable.

[JASpup]

Looking it seems some of my boots already have an adrv, making me hesitant to just replace them with the pupsave in use.

I have to think about what's loaded into ram or not, now not particularly concerned about system sfs, but everything else.

Example: intermediate user renames a pupsave he likes to adrv, not realizing the adrv is a layer in ram without specifying NOCOPY, while the pupsave was not. He thought he was just creating a more resilient system booting PUPMODE 5, but actually is hurting system performance with wasteful ram usage.

EDIT: Just looked - 32 Xenial has a default 460k adrv. Tahr 6.0.5 has none.

ALL additional drives like adrv, bdrv are normal sfs files as mentioned before. They are named adrv, etc. for a specific reason, ie. that the init script loads them automatically at bootup to a specific layer. If you boot with pfix=nocopy, the RAM usage in terms of mere loading the sfs (adrv or whatever other extra sfs file) is basic neglectable.

[amethyst]

Looking it seems some of my boots already have an adrv, making me hesitant to just replace them with the pupsave in use.

I have to think about what's loaded into ram or not, now not particularly concerned about system sfs, but everything else.

Example: intermediate user renames a pupsave he likes to adrv, not realizing the adrv is a layer in ram without specifying NOCOPY, while the pupsave was not. He thought he was just creating a more resilient system booting PUPMODE 5, but actually is was hurting system performance with wasteful ram usage.

ALL additional drives like adrv, bdrv are normal sfs files as mentioned before. They are named adrv, etc. for a specific reason, ie. that the init script loads them automatically at bootup to a specific layer. If you boot with pfix=nocopy, the RAM usage in terms of mere loading the sfs (adrv or whatever other extra sfs file) is basic neglectable.

As mentioned, any sfs file can be called an adrv/ydrv. Some developers include an application (like a browser) as an adrv. I use an adrv fot system changes. Again, if you boot with pfix=nocopy the RAM usage for LOADING the sfs is small (about 10MB per sfs loaded). So unless you load tens of sfs's it will not really make a dent in RAM usage. Of course when you start to use an application (whether it's a loaded sfs file or installed application in your savefile) the additional RAM used for running the application will be similar. BTW: You can't just rename a savefile/folder to an adrv, you need to compress the contents into an sfs file.

[JASpup]

The sfs_load application will typically ask you if you want to copy it to RAM if it is not located at /mnt/home or located at the same location as your Puppy files.

The only prompt I've noticed is to copy the .sfs in process of being loaded to /mnt/home, not ram.

Are you stating that if the .sfs is not in /mnt/home, Puppy will copy it to ram?

Re. modes, so long as we can force PUPMODE 13 on an internal hd frugal install we're o-kay.

[JASpup]

As mentioned, any sfs file can be called an adrv/ydrv. Some developers include an application (like a browser) as an adrv.

I need to figure out if that's where Pale Moon is. 25 is a problem in Tahr.

You can't just rename a savefile/folder to an adrv, you need to compress the contents into an sfs file.

My understanding is the opposite.
ozsouth: viewtopic.php?p=25123#p25123

So a .2fs has to be converted to a .sfs.

(I just use files)

[amethyst]

The sfs_load application will typically ask you if you want to copy it to RAM if it is not located at /mnt/home or located at the same location as your Puppy files.

The only prompt I've noticed is to copy the .sfs in process of being loaded to /mnt/home, not ram.

Are you stating that if the .sfs is not in /mnt/home, Puppy will copy it to ram?

Re. modes, so long as we can force PUPMODE 13 on an internal hd frugal install we're o-kay.

If your extra sfs is not in /mnt/home or at the location where your Puppy BASE sfs is located, the sfs_load application will ask if you want to copy the sfs file to RAM (which you can accept or decline). This is a safety measure. In terms of pupmodes, depends how you run Puppy. I have a harddrive and operate without a savefile (running in pumode 5). But I agree, if you have a harddrive and working with a savefile, the better option is to run in pupmode 13 so that you have control when to save your session (the disadvantage is of course that if you have a crash or power failure, you will lose the session system changes which were not saved).

[amethyst]

As mentioned, any sfs file can be called an adrv/ydrv. Some developers include an application (like a browser) as an adrv.

I need to figure out if that's where Pale Moon is. 25 is a problem in Tahr.

You can't just rename a savefile/folder to an adrv, you need to compress the contents into an sfs file.

My understanding is the opposite.
ozsouth: viewtopic.php?p=25123#p25123

So a .2fs has to be converted to a .sfs.

(I just use files)

.2fs, 3fs, 4fs are filesystems which contains files in an uncompressed state. An SFS file is a read-only archived format which contains contents which are compressed with a compressor algorithm like gzip, xz, etc. Yes the CONTENTS (files) in the .2fs (filesystem) can be compressed/built as(into) an sfs file with a compressor as mentioned.

[JASpup]

If your extra sfs is not in /mnt/home or at the location where your Puppy BASE sfs is located, the sfs_load application will ask if you want to copy the sfs file to RAM (which you can accept or decline). This is a safety measure.

sfs_load-nocopy.png (21.85 KiB) Viewed 844 times

It looks like the sfs_load question posed here is for copying SFS to media. I happen to be in MODE 5 (usually in 13). The dropdown lists every connected partition.

It has a preference for the boot partition. I've seen other similar messages, possibly because this .sfs happens to be in /root (ramdisk).

What does the last paragraph mean?

"Puppy space(RAM but need to copy)."

Need?

If I don't copy, it still loads.

[JASpup]

.2fs, 3fs, 4fs are filesystems which contains files in an uncompressed state. An SFS file is a read-only archived format which contains contents which are compressed with a compressor algorithm like gzip, xz, etc. Yes the CONTENTS (files) in the .2fs (filesystem) can be compressed/built as(into) an sfs file with a compressor as mentioned.

The pupsave isn't compressed, got it. That makes sense. They compress well in archives.

You mean I don't just compress the .2fs to a .sfs? I need to extract the pupsave contents and .sfs that?

[amethyst]

That means that if you want the sfs to be copied to RAM, you need to choose that option.

[JASpup]

That means that if you want the sfs to be copied to RAM, you need to choose that option.

I don't see that option. Never have. If the .sfs is not in /mnt/home, it will copy it there, or in this PUPMODE 5 example with the .sfs in /root, I have the option of copying it to a partition, not unlike how the system searches for a location for a pupsave and lists all possible partitions.

[amethyst]

.2fs, 3fs, 4fs are filesystems which contains files in an uncompressed state. An SFS file is a read-only archived format which contains contents which are compressed with a compressor algorithm like gzip, xz, etc. Yes the CONTENTS (files) in the .2fs (filesystem) can be compressed/built as(into) an sfs file with a compressor as mentioned.

The pupsave isn't compressed, got it. That makes sense. They compress well in archives.

You mean I don't just compress the .2fs to a .sfs? I need to extract the pupsave contents and .sfs that?

No. An application (like Packit) can create the sfs file for you if you highlighting the files in the folder, right-click it and run the application from the right click menu. "Under the hood" it uses the mksquashfs command. Type mksquashfs --help in the terminal to see how to create an sfs file manually (this will also give you an idea how it works).

[JASpup]

No. An application (like Packit) can create the sfs file for you if you highlighting the files in the folder, right-click it and run the application from the right click menu. "Under the hood" it uses the mksquashfs command. Type mksquashfs --help in the terminal to see how to create an sfs file manually (this will also give you an idea how it works).

No, I just need to mksquashfs the .2fs file in PackIt?

I don't use save folders, so I don't know if you mean the .2fs contents or just the file itself.

[amethyst]

That means that if you want the sfs to be copied to RAM, you need to choose that option.

I don't see that option. Never have. If the .sfs is not in /mnt/home, it will copy it there, or in this PUPMODE 5 example with the .sfs in /root, I have the option of copying it to a partition, not unlike how the system searches for a location for a pupsave and lists all possible partitions.

Okay, it seems I've misguided you. If the sfs is not in /mnt/home the application can load it in RAM (you choose nocopy) or you can choose to copy it to /mnt/home or the location where your base sfs is (in which case it will not be copied to RAM).

[JASpup]

If the sfs is not in /mnt/home the application can load it in RAM (you choose nocopy) or you can choose to copy it to /mnt/home or the location where your base sfs is (in which case it will not be copied to RAM).

You're stating behind-the-scenes loaded .sfs are copied to ram if they are not in /mnt/home, either by being loaded from or copied to that folder, even if the source .sfs remains available?

[amethyst]

No. An application (like Packit) can create the sfs file for you if you highlighting the files in the folder, right-click it and run the application from the right click menu. "Under the hood" it uses the mksquashfs command. Type mksquashfs --help in the terminal to see how to create an sfs file manually (this will also give you an idea how it works).

No, I just need to mksquashfs the .2fs file in PackIt?

I don't use save folders, so I don't know if you mean the .2fs contents or just the file itself.

THE CONTENTS. 2.fs is not a file, it's a filesystem as mentioned. The contents of .2fs (which is your savefile). So to pack the CONTENTS of your savefile as an sfs file: You can highlight the folders and files as displayed in the /initrd/pup_rw (folder) and create the sfs with PackIt as mentioned.

[JASpup]

THE CONTENTS. 2.fs is not a file, it's a filesystem as mentioned. The contents of .2fs (which is your savefile). So to pack the CONTENTS of your savefile as an sfs file: You can highlight the folders and files as displayed in the /initrd/pup_rw (folder) and create the sfs with PackIt as mentioned.

O-kay I will try it. I presume you mean ro1 as the pupsave layer in PUPMODE 13.

[amethyst]

If the sfs is not in /mnt/home the application can load it in RAM (you choose nocopy) or you can choose to copy it to /mnt/home or the location where your base sfs is (in which case it will not be copied to RAM).

You're stating behind-the-scenes loaded .sfs are copied to ram if they are not in /mnt/home, either by being loaded from or copied to that folder, even if the source .sfs remains available?

Loading the sfs from any location and copying the sfs file are two different things as explained to you earlier.

[amethyst]

THE CONTENTS. 2.fs is not a file, it's a filesystem as mentioned. The contents of .2fs (which is your savefile). So to pack the CONTENTS of your savefile as an sfs file: You can highlight the folders and files as displayed in the /initrd/pup_rw (folder) and create the sfs with PackIt as mentioned.

O-kay I will try it. I presume you mean ro1 as the pupsave layer in PUPMODE 13.

/initrd/pup_ro1 (the existing savefile) AND /initrd/pup_rw if you also want to include the changes of the session. AGAIN: My nicOS-save2SFS utility does this for you in the correct order.

[JASpup]

If the sfs is not in /mnt/home the application can load it in RAM (you choose nocopy) or you can choose to copy it to /mnt/home or the location where your base sfs is (in which case it will not be copied to RAM).

You're stating behind-the-scenes loaded .sfs are copied to ram if they are not in /mnt/home, either by being loaded from or copied to that folder, even if the source .sfs remains available?

Loading the sfs from any location and copying the sfs file are two different things as explained to you earlier.

It's not misunderstood. I just want to know why you insist .sfs are copied to ram if they're not in /mnt/home.

[amethyst]

You're stating behind-the-scenes loaded .sfs are copied to ram if they are not in /mnt/home, either by being loaded from or copied to that folder, even if the source .sfs remains available?

Loading the sfs from any location and copying the sfs file are two different things as explained to you earlier.

It's not misunderstood. I just want to know why you insist .sfs are copied to ram if they're not in /mnt/home.

Where do I say that? LOADED (it then uses about 10MB for the loading process). So to be clear: an sfs can be loaded from any location but you have the option to move or copy it to /mnt/home or the location of the base sfs. I've seen versions of sfs_load which also gives the option to COPY the sfs file to RAM.

[JASpup]

/initrd/pup_ro1 (the existing savefile) AND /initrd/pup_rw if you also want to include the changes of the session. AGAIN: My nicOS-save2SFS utility does this for you in the correct order.

Since I wouldn't know how to easily include two directory contents without checking out the command line version, I would probably save any changes to the pupsave and just sfs that.

[JASpup]

Where do I say that? LOADED (it then uses about 10MB for the loading process).

Instead of rehashing particulars, I'll presume we have the same understanding that either way we're not getting ram copies, but the sfs_load process does use a chunk of ram each load.

If a consistent 10M for each .sfs, that's modest for the big ones. For the lightest browser I use, it's about half.

[amethyst]

/initrd/pup_ro1 (the existing savefile) AND /initrd/pup_rw if you also want to include the changes of the session. AGAIN: My nicOS-save2SFS utility does this for you in the correct order.

Since I wouldn't know how to easily include two directory contents without checking out the command line version, I would probably save any changes to the pupsave and just sfs that.

You don't have to do that. Just take the easy option and use my utility?

[amethyst]

Where do I say that? LOADED (it then uses about 10MB for the loading process).

Instead of rehashing particulars, I'll presume we have the same understanding that either way we're not getting ram copies, but the sfs_load process does use a chunk of ram each load.

If a consistent 10M for each .sfs, that's modest for the big ones. For the lightest browser I use, it's about half.

It's around 10MB more or less despite the size of the sfs file. Remember, you are not COPYING it you are only LOADING it. BIG DIFFERENCE.

[JASpup]

Just take the easy option and use my utility?

I need to know what's going on before shortcuts, learning curve.

[amethyst]

Just take the easy option and use my utility?

I need to know what's going on before shortcuts, learning curve.

Well, good luck then with your learning curve.