It is possible.
Note: my experience in the subject is very limited; the following answer is based mainly on web research, I haven't verified this in practice myself.
In general, whatever you mount to a
/foo/bar/mountpoint, it completely covers the previous content of the
mountpoint (although programs keep their already obtained handles to now "hidden" files, they are still valid). Your second bind mount did just that.
The trick is to use a mount type that combines two or more directories into one. The general concept is called union mount. There are several implementations:
In general a union may be mounted over one of the combined directories or to a completely different (preferably empty) mountpoint. In my opinion the latter is more elegant solution.
These are some aspects you may want to consider while choosing a union mount type for your needs:
- Some of them are available only as FUSE, some are merged into the Linux kernel (in this case they may have FUSE implementations as well). Check these security concerns regarding FUSE.
- What happens when you alter one of the combined directories directly? (example issue).
What happens when you add a new file to a union. Mhddfs seems promising for merging directories containing media files. Check this article, it says:
When you create a new file in the virtual filesystem,
mhddfs will look at the free space, which remains on each of the drives. If the first drive has enough free space, the file will be created on that first drive. Otherwise, if that drive is low on space (has less than specified by
mlimit option of
mhddfs, which defaults to 4 GB), the second drive will be used instead. If that drive is low on space too, the third drive will be used. If each drive individually has less than
mlimit free space, the drive with the most free space will be chosen for new files.
It's even more than that; if a certain drive runs out of free space in the middle of a write (suppose, you tried to create a very large file on it), the write process will not fail;
mhddfs will simply transfer the already written data to another drive (which has more space available) and continue the write there. All this completely transparently for to the application which writes the file (it will not even know that anything happened).
I don't know how other implementations handle this. I guess they were originally created to allow uniting a write-capable filesystem with a read-only one (like in this question), so any of them may not be as flexible as mhddfs when it comes to (re)distributing files. I'm not sure though, you may want to test it on your own.