What Directory Areas are Not Saved in upper_changes?

[JusGellin]

I'm unclear for what linux folders or areas are not stored when a save to the upper-changes folder occurs.
For example I would like to store my virtual machine images (*.qcow2) to a place that wouldn't get saved because these can get to be very large.

Where can I put files like this that don't need to be saved? I would like to have a better understanding of what is saved and what isn't

Thanks

[wiak]

I'm unclear for what linux folders or areas are not stored when a save to the upper-changes folder occurs.
For example I would like to store my virtual machine images (*.qcow2) to a place that wouldn't get saved because these can get to be very large.

Where can I put files like this that don't need to be saved? I would like to have a better understanding of what is saved and what isn't

Thanks

It is simple actually but far from obvious.

In short, store your qcow2 or whatever files anywhere on any partition that has been "specially mounted" read/write. Mounted filesystems aren't copied into RAM so anything written into them goes direct and doesn't get temporarily stored in RAM.

Writing anything new into main merged filesystem otherwise goes into RAM if using wd_changes=RAM2 mode. In that case the tmpfs in RAM is merged filesystem location /mnt/layers/RAM/upper_changes/ which only gets rsync merged into actual media upper_changes directory when save2flash is run.

Short of time tonight, but I'll write examples to explain better in a day or two when I finish some things I need to take care of.

[JusGellin]

In short, store your qcow2 or whatever files anywhere on any partition that has been "specially mounted" read/write. Mounted filesystems aren't copied into RAM so anything written into them goes direct and doesn't get temporarily stored in RAM.

That's exactly what I want to do.
I can give the qcow2 image a specific location to store.
In fact virt-manager has a feature to make a storage pool.
Inside this pool can be volumes that would contain these images.

So perhaps the storage pool could be the thing that is mounted that would open up all the images it has as stored volumes.
For example the default pool is at location /var/lib/libvirt/images, but new pools can be created and placed anywhere and that's what I would like to do..
I just don't know how to go about mounting this to make it available.

Thanks for your help in your busy schedule.

[wiak]

I just don't know how to go about mounting this to make it available.

Thanks for your help in your busy schedule.

Until I get round to explaining this better, for now just remember the partition you have booted your frugal install from is mounted (has to be). You can thus create a new directory anywhere in that partition and simply save your qcow2 files there and no upper_changes save2flash mechanism is involved or affected. You can usually 'see' the bootfrom partition when you open Filemanager in KL and go to /mnt; the bootfrom partition should be in an appropriately named folder there so you can make new directory in that and copy your qcow2 files or whatever.

EDIT: see below post since what I wrote here doesn't seem to be quite correct.

[wiak]

EDIT to the above post. I was in Linux Mint normal full install when I wrote that so couldn't check, but now booted KL Manjaro XFCE and note location is different: on that one the bootfrom partition was /media/root/<name_of_the_bootfrom_device/

Of course you'd have to open a root user filemanager to copy files into that partition unless you had previously set some area up for normal user read/write access.

Not sure why /mnt/<name_of_the_bootfrom_device/ was empty on that one; been a while since I wrote the initrd/init script so may have forgotten some change or perhaps the distro creator modified it for their own purposes.

I just checked my commandline only version of under test KLU_Noble and the bootfrom partition is indeed visible inside /mnt. I think indeed therefore that the w_init routine concerned probably slightly modified for KL Manjaro XFCE to use /media hierarchy, which does indeed work better for auto-seeing in the likes of Thunar and PCmanFM - I've don't the same myself in the past and thought of doing so again but haven't for some reason - maybe breaks some of the earlier firstrib utility tools, but I'll have to look into that again sometime to see if that was why. I'm actually not sure why /media gets used nowadays - probably some new Filesystem Hierarchy Standard decision choice - and /mnt used for maybe removable storage only(?) - I've read about all these possibilities recently, but the details escape me right now. EDIT: Actually it should be the other way round... /media is supposed to be used for mounting removable media and udev can use /media/<login_username> hence if logging in as root user the removable device should be seen at /media/root/blahblahblah. I would think the bootfrom partition, if on hard disk, which is what I generally use should normally be seen somewhere hanging off /mnt therefore, but FirstRib initrd/init does differentiate between booting from removable media or hard disk so becomes a matter of choice in that sense.

For a post re /mnt versus /media, refer for example to: https://www.linuxquestions.org/question ... 175542536/

[JusGellin]

You can usually 'see' the bootfrom partition when you open Filemanager in KL and go to /mnt; the bootfrom partition should be in an appropriately named folder there so you can make new directory in that and copy your qcow2 files or whatever.

Great clue - it worked!!

My save folder is at /mnt/sda2/KLV-vmHost-rc2
I put the folder to put the qcow2 images in at /mnt/sda2/vms
From virt-manager I made a storage pool that pointed to /mnt/sda2/vms.
Then made a volume in it with the storage size I wanted in that.

I built the vm and made it work and saved it and exited.
Then I did a save2flash and noticed it was quick -- like it didn't save the image this time.
Did a reboot and could see in the upper_changes folder that it was only 5.5M (not the full size of the image like before)
So the image wasn't saved there this time and on a reboot the vm still worked from the image.

All right! This will be very useful for me.
Thanks