Mounting two or more 2fs files. (Solved, sort of)

[Uten]

Hello,

I wonder if anyone have experimented with mounting two 2fs files at the same time?

Say, I would have the regular 2fs file mounted and then one on top of that to cover my personal stuff like the folders ~/mail, ~/my-documents and ~/web-server.

My understanding of 2fs files are that they are similar to sfs files. We can mount several sfs files and their folder/file structure is transparently placed on top of the previous one. The big difference is that a 2fs file is writable whereas the sfs files are not.

Are there technical challenges to implement my scenario?
Which files should I look at to implement something like this.?

As a side-note I'm already using a separate encrypted img file mounted on my my-documents folder. But it would be so much better if I could cover all my personal folders with one file.

Best reaards
Uten

[disciple]

Only the top layer in a unioned system can be writeable. As you obviously know, you can mount an extra .2fs to any given folder. Or you could just move the other folder into the .img file that contains your my-documents, and create symlinks to them.

[Uten]

Only the top layer in a unioned system can be writeable.

I think that is a misunderstanding, or only true (a feature if you like), to the way puppylinux uses unionfs. It could also be the case for the system used in the 1.x branche of puppy.

From what I read at http://unionfs.filesystems.org/ and http://en.wikipedia.org/wiki/UnionFS it should be possible to have several read-write layers stacked upon each other. (I have to verify this in regards of loop mounted file images ).

Reading

Puppy2 leverages off the unionfs layer management mechanism. Basically, the top layer (pup_rw), is a tmpfs filesystem in ramdisk, containing all the new and changed directories and files.

indicates that your claim is true to puppylinux (by design) but not to a unioned system in general.

howpuppyworks.html points me to /sbin/init. I think quite a bit of the code has been moved to /etc/rc.d/rc.update. I'm trying to figure out how works, and how it fits in the puzzle.

I could also go the easy route and use symlinks as you pointed out, but what is the fun in that

[RetroTechGuy]

Only the top layer in a unioned system can be writeable.

I think that is a misunderstanding, or only true (a feature if you like), to the way puppylinux uses unionfs. It could also be the case for the system used in the 1.x branche of puppy.

Well, I don't know what is "supposed to happen", but I regularly open .2fs files, to copy, modify, or purge the contents (typically when migrating from one version OS to another).

The only restriction that I've found is that they cannot have the same name (even though in different paths). If the .2fs is corrupted, I think it is restricted to read-only, but unmount the file system, then "fsck /mnt/home/oldjunk/broken.2fs" will scan and repair the file system, and it will mount read-write on the next mount.

Clicking on the file once mounts the file system. Clicking the file a second time umounts the file system.

Edit: Oh, rereading, I see that you just want to chose different mount points. That too can be done (the .2fs files just think that they are independent ext2 partitions).

I solved the email issue by storing it in /mnt/home (I use thunderbird, and just dragged a symlink in as .thunderbird)

[Uten]

Thanks for the suggestions.

What I want is the transparent behavior unionfs is designed to handle.

This is my test system:

sh-4.1# cat /etc/DISTRO_SPECS
#One or more words that identify this distribution:
DISTRO_NAME='Lucid '
#A three-digit numeric value, version number of this distribution:
DISTRO_VERSION=528
#A two-digit numeric value, minor-version number of this distribution:
DISTRO_MINOR_VERSION=00
#The distro whose binary packages were used to build this distribution:
DISTRO_BINARY_COMPAT='ubuntu'
#Prefix for some filenames: exs: lupusave.2fs, lupu-528.sfs
DISTRO_FILE_PREFIX='lupu'
#The version of the distro whose binary packages were used to build this distro:
DISTRO_COMPAT_VERSION='lucid'
#the kernel pet package used:
DISTRO_KERNEL_PET='linux_kernel-2.6.33.2-tickless_smp_patched-L3.pet'
#16-byte alpha-numeric ID-string appended to vmlinuz, lupu_528.sfs, zl528332.sfs and devx.sfs:
DISTRO_IDSTRING='l528120404231153'
#Puppy default filenames...
#Note, the 'SFS' files below are what the 'init' script in initrd.gz searches for,
#for the partition, path and actual files loaded, see PUPSFS and ZDRV in /etc/rc.d/PUPSTATE
DISTRO_PUPPYSFS='lupu_528.sfs'
DISTRO_ZDRVSFS='zl528332.sfs'
sh-4.1#

This is a mock up. To implement it against /root needs a bit more consideration as there is a lot more going on in that folder than I thought.

First make a img file. In this case it is created on the disk, not in the save file.

#>dd if=/dev/urandom of=/mnt/home/myroot.img bs=1M count=5

Then make a file system on it (use ext2 if you want encryption) and mount
Notice! You should probably not use /tmp on a production system. this is for a demo.

mkfs.ext2 /mnt/home/myroot.img
mkdir /tmp/myroot
mount -o loop /mnt/home/myroot.img /tmp/myroot

Make a test folder with some stuff in

mkdir -p /tmp/mystuff/my-app
touch /tmp/mystuff/README.txt

Then merge the folder and the image. Content in the mount point (folder) will not be visible.

mkdir /tmp/dirs
mount -t aufs -o br=/tmp/dir1=rw:/tmp/myroot=rw:/tmp/mystuff=rw none /tmp/dirs

Check that you find what you expect

find /tmp/dirs

I have written this down from the top of my head so be aware of and kind to typos. As I want my img (2fs) files to be encrypted I did all my testing with that, but it complicates the creation of an img file slightly. I will experiment a bit with replacing /root later this weekend.

Best regards
Uten