Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Overlayfs (Merging folders)

Off-Topic discussions about science, technology, and non Debian specific topics.
Post Reply
Message
Author
User avatar
bester69
Posts: 2072
Joined: 2015-04-02 13:15
Has thanked: 24 times
Been thanked: 14 times

Overlayfs (Merging folders)

#1 Post by bester69 »

Hi,

Have you tried this tool? :roll: , seems interesting concept, Im interesting in learn how to merge folders (different/several concepts and so)

Overlayfs
Union file systems are a creative solution to allow a virtual merge of multiple folders, while keeping their actual contents separate.
https://www.datalight.com/blog/2016/01/ ... -it-works/

Image

Seems a good tool, I will give it a try eventually
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...

User avatar
bester69
Posts: 2072
Joined: 2015-04-02 13:15
Has thanked: 24 times
Been thanked: 14 times

Re: Overlayfs (Merging folders)

#2 Post by bester69 »

Nice and interesting Tool, very usefull to merge two folders..

For example, Ive got two folders, One encrypted one and other one without encryptation, sharing both of them some of same directories...Im going adding files to both branches, and sometimes I need to mount encrypted branch and merge it with the unecrypted directory to contrast information.
see how it goes.:
1- Uncrypted folder named: SEGUROUT
2- Encrypted folder namer: SEGURCRYPT (encfs encryptation)
3- Mount merge SEGUROUT into mounted-SEGURCRYPT (overlay)

Using overlayfs, it would be such an easy like this.:

Code: Select all

#!/bin/sh
#
workpath=/home/user/overlayfs

sudo umount $workpath/segurout
sudo umount $workpath/overlay
sleep 1
sudo mount --bind -o ro $workpath/segurout $workpath/segurout
sudo mount -t overlay -o \
lowerdir=$workpath/segurout,\
upperdir=$workpath/segurcryp,\
workdir=$workpath/tmpwork \
none $workpath/overlay
Give it a try, Its really cool :o
bester69 wrote:STOP 2030 globalists demons, keep the fight for humanity freedom against NWO...

CwF
Global Moderator
Global Moderator
Posts: 2636
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Overlayfs (Merging folders)

#3 Post by CwF »

If the overlay could reach out on the network and combine the home directory (exclude .) for a single user on multiple vm's that would be nice.

From the info graphic, the 'lower' could be a common backing file qcow2. Many 'Upper' layers running on that vm with a common user. Then the 'overlay' layer is then a single layer merging /home from the many 'upper' layers. I would want that last layer to be the actual location, maybe a dedicated vm layer and have the files vitual for the other vm's.

Neato complexity.

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Overlayfs (Merging folders)

#4 Post by p.H »

bester69 wrote:seems interesting concept
You probably already used a union mount without knowing it if you have ever used a live system. Live systems use it to merge a read-only filesystem (often squashfs) and a read-write memory-based filesystem (usually tmpfs).

ruffwoof
Posts: 298
Joined: 2016-08-20 21:00

Re: Overlayfs (Merging folders)

#5 Post by ruffwoof »

Indeed live-boot uses squashed filesystems (sfs) and overlays. Main read only sfs at the bottom, a rw save area on top. Looks down and if the file is in the save area then that is used, otherwise reads from the ro sfs. whiteout files (.wh) are used to indicate if a file has been deleted i.e. still in the bottom ro, but if a .wh file exists in the save area that indicates the file isn't available.

Gets more interesting if you use lz4 for the sfs compression. Its multi core decompression speeds can approach ram bus speeds. Most sfs's however are commonly compressed with gzip.

My secondary boot is EasyOS. In that you boot the main sfs (with its own save area, Debian live-boot tends to use a save partition as the save area, however more generally that can alternatively be a folder). Then you can create a chroot container. Normally you load/setup a chroot with a os within that, however in EasyOS's case that's just a pointer ... to the same sfs that the main system booted from. That chroot then has its own separate save area. Fundamentally in EasyOS it uses the main sfs at the bottom layer, its own save folder area, and sets up a Xephyr desktop that along with chroot and dropping capabilities ...etc makes that 'container' relatively secure and isolated from the main system. This for instance is my EasyOS desktop container that I run firefox ...etc within
Image
ps provides a indication of the limitations i.e. PID 1 is a script. Whilst I run as root within that container, root is severely crippled to the extent it comparable to a heavily restricted userid. To mount things for example I have to flip from that to a more authoritative userid/desktop/tty.

Another benefit is that you can create snapshots of the container i.e. save the save area to a sfs - which is just the list of changes. And then roll back or forward between snapshots (i.e. restore the save area from a particular snapshot sfs to the save area).

sfs's are a interesting subject to become familiar with. When I ran Debian as my primary boot I used to do a full install, and the install live-boot on top of that, with a empty main sfs. Label the main (full install) as 'persistence' and that becomes the live-boots save area. That way you can live boot, do things and then not save at the end, so no changes are preserved. Great for trying things out. Or for updating just normal (full main system/standard) boot and apply the updates (apt-get update). Best of both worlds.

Post Reply