Merging several trees

[xennex81]

I have a question about how to move several trees together under the same directory structure. These are usually referred to as mount points, but the problem with mount points is that they have to come from a physical volume or some loopback device volume.

Suppose you have a common directory like /usr/local/ and you want to mount several volumes beneath it.

One way to do it is to use a different volume for each and every directory. E.g. there can be directory "games" and it is located on a volume such as /dev/mapper/group-games. Another directory is "share" and it is located on a volume such as /dev/mapper/group-share. The downside of this is that these volumes are physically separated and they have fixed boundaries in allocation space.

What that means is that you now have clear mount points but you have to put your files on several volumes.

Now you might also have a volume that contains several of these directories. Call them /share and /games. You want to mount that volume under /usr/local. Fair enough.

Then you have another volume and it contains /setup and /download. You also want to mount it under /usr/local. Is this possible?

The only thing I know of is using overlays. But an overlayfs will have one upper and one lower. Moreover, it requires both upper and lower to be mounted elsewhere, or at least mounted somewhere ( I believe one of them may already be mounted on the merged mountpoint ).

So you can have:

mount /dev/mapper/group-one /usr/local/
mount /dev/mapper/group-two /somewhere
mount -t overlay /usr/local -o lowerdir=/usr/local,upperdir=/somewhere

And it will merge the directories, but now you have /somewhere mounted in two positions.

What is more: all the changes always go to the upper dir. You cannot have a overlay mount and have the changes written to the subsequent trees. That is to say, now all the directories in /somewhere get their changes written to /usr/local on /dev/mapper/group-one.

What I want of course, what you want of course, is for your changes to be written to the respective trees for the respective volumes, or you create real nightmares.

This however requires simply mounting with a bind operation, some part of a tree somewhere else. You could do

mount -o bind /somewhere/setup /usr/local/setup and it would work.

BUT THAT LEAVES a mountpoint visible elsewhere as well and this is not nice for a security perspective as well as presentation to unwilling users like yourself. You want this data to be accessible in only one way. They call it the "canonical" url supposedly and it is important for e.g. search indexing. You don't want e.g. your site to appear under two links in a google index, but it is the same for a local system.

Now there is UnionFS

There is a package aufs-tools and a package unionfs-fuse. The latter provides the filesystem in user space, which I do not want.

The OverlayFS is considered a form of UnionFS, so basically it seems that there is not really any UnionFS anymore in Linux. OverlayFS is supported by the Linux kernel although documentation seems to be scarce.

Hiding a mount point that has already been mounted with some filesytem prior to the union mount can only really be done by mounting an empty directory on top of it.

The aufs-tools package allows to easily create a mounted merged directory using for example: mount -t aufs br:/firstdir=rw:/seconddir:rw none /merged and it will work as intended straight away. The manual page however is horrendous to read.

I am wondering what thoughts you have? The merged directory with aufs is completely merged. Writing to one subdirectory will just write to one of the filesystems. Changes written to the total root of the merged directory is just written to the former. I'm not sure how it works further than that, but I can use it right away as long as I study it a bit more.

[oshunluvr]

I don't understand the objection to having something mounted somewhere twice. Unless this is an intellectual exercise - you just want to see if it can be done - why care if /mnt/bob and /mnt/carol are also /usr/local/ted and /usr/local/alice?

I guess my questions is: What's the damage caused by having the same device mounted in more than one location? It's done all the time.

[kubicle]

There is bindfs, which sort of resembles bind mounts, but you can have different ownerships/permissions for the mounts so it's somewhat more versatile.
As bindfs uses fuse mounting, it'll mean an I/O performance hit (how noticeable or severe that is depends on how it is used).

You can also use simple linking (hard or soft) which is fast, simple and easy (but based on what you posted, may not meet your needs)

[xennex81]

It pertains to issues of presentation. The root filesystem is littered with directories in any case and they have become more in recent years. Mac OS solved that by putting everything under /System, /Applications and /Users, I believe. You are getting issues with neatness from a user point of view. It is a feminine aspect, I think. And I can tell you there is not much femininity in Linux.

The problem also arises with file searches and so on traversing the same tree twice. I'm not sure it can be prevented with .e.g xdev options. Cross-dev options. It is just not handy to have the same thing visible twice. It is not about it not being there, you just want one access path : the canonical url. But in essence I am answering something that is already answered in my post: I am the fool again. There was a user on some forum that asked the same question as I do now, only from a bit of a different point of view. He was likewise ridiculed.

There was a guy who kept saying "it is the wrong thing to want". "That's the wrong thing to do it." But there is more than one way to choke a cat (with cream). It doesn't have to be your way. Now if this new view was really a different, changing view on the same dataset, I wouldn't care. But there is no benefit to having a merged directory visible elsewhere as well, if there is no additional information presented.

So the question is not: why, but why not?

[xennex81]

Thank you! Bindfs is very useful, but it seems to be about permissions only.