I wanted a link that points to many targets.
I found a mount that combines many targets ( the reverse ).
It`s like a union without the complexity and problems.
Tests showed it had no cpu load ( it`s just a mount ) and no ram use.!
It can be used to combine partitions into one, and dirs. too.
# And... It got 5 a star rating.!

It`s called "mhddfs", it uses Fuse and is simple to use.
It merged 2 dirs. with files and another with a link as it`s path.
# NOTE: Be sure to use the / at the end of the mount point or it adds /root ( don`t know why...).

I haven't tested it, but I'll hazard a guess - all the underlying filesystems must be writable; so deleting a file will actually delete it from the underlying filesystem. Now how it handles files / directories with same name will be interesting ... e.g you have to dirs with the same name in /sdb1/0 and /sda1/0, when you delete /virtual/0 what would happen ... I'll guess again it will delete *both*._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

"The results are painful, mhddfs introduces a huge overhead."
"FUSE? yuck.. so not even kernel level.. You sure you want to store your files that way?"
"Well, assuming that mhddfs/fuse causes lower performance, your options would be:"

For most use cases, the penalty from using FUSE is likely not a problem.

Somehow I had never been aware of mhddfs. It seems to be tailored to the specific use-case: User wants to combine multiple hard-drives into a single 'view', with normal ability to add or delete files.

Aufs can also use multiple write-layers. Unionfs can only use one write-layer. Unionfs and aufs both operate at the kernel-level, so throughput penalties are minimal. unionfs has the advantage of being part of the mainline kernel code, though this may not always be so.

aufs is actually less invasive to kernel code, but is much larger than unionfs code(because it has the most features). Mainline kernel devs want (or could accept) union *mounts*, but not more union file systems. A union mount is only for a single device, one level deep, whereas union file systems can be multi-level.

My src2pkg uses either in-kernel unionfs or (default) the FUSE-based unionfs-fuse program to create limited unions.

For the purpose of having a read-only file system act like a writable FS using a 'save-file' or save drive, aufs is most flexible.

disciple; White out files are only needed for non-writable layers I think.
As amigo says, the unionfs only has the top writable layer.
The web site said it used almost no resources, but maybe not fuse...

Karl; Unionfs was all there was for a long time, but aufs is much better.
Unionfs had problems when Barry started using it on / .

jamesbond; I believe the web site said it acts on the first file in the list.
So then it behaves just like a path with a hierarchy. That makes sense.

jpeps; Apparently web site claims and user experience is different.
Write slowdowns were solved by using aufs instead.
I figured with the simpler layout of mhddfs it`d be faster.

amigo; It`s not so much making a r/o fs act r/w as combining dirs.

# As I see it, the dir. /usr/share is the place for most app. deps.
I need to combine the main /share with all the separate app. pkgs.
So when the app. looks for deps. they appear in the correct place.
Using a union to do this would mean many layers, but small dir. trees.
There are probably other dirs. that need this also.

Exec. use PATH, and libs. use LD_LIB_PATH, but normal files have none.
So I hatched the idea of a multi. target link, with low resource usage.
It doesn`t try to combine dir. trees, it just points to multiple targets.

Mhddfs is simpler than aufs, but sadly that doesn`t mean it`s better.
Aufs may very well preform faster with less cpu overhead.
I did not want a full blown union, but for my intended limited use...
Perhaps mhddfs will be kernelized, or someone will make a multi. link.
.Last edited by sunburnt on Thu 21 Jun 2012, 17:36; edited 1 time in total

Karl; I think your setup would do the usual mount thing of stacking.
Each mount covers the previous one, I think that`s mhddfs purpose.
But it may work the way you`ve proposed, it`d be interesting to see.

vovchik; I`m hoping it can work out for what I need. Aufs is overkill.
I`ve had thoughts about it, and I`ll elaborate more below.

# I think the reason for mhddfs slow writes is due to it`s checking
the mount`s sizes each time. It would be faster at it, if it kept a list.
This would explain the big difference in read / write times reported.
If it just wrote to the first mount until a full error and then the second.

For my purpose, I only need to read from the common /share mount.
So perhaps the cpu load won`t be so bad. I`ll test a little and report.

Sadly my mounts are dirs., so there`s no reason to check their size.
And it`d be really nice if it could remount to add / remove branches.
One can only hope that mhddfs is improved on and features added.

My main thought: Are there any other dirs. app. deps. are kept in?
The Linux dir. tree is large and the rest of it can`t be just for the O.S.
Some of /share is not deps., and /local has very little in it, in Puppy.
/root has config. files and likely other stuff too, but no deps I think.
.Last edited by sunburnt on Fri 22 Jun 2012, 01:22; edited 2 times in total

Update: I renamed /usr/share to /usr/share_0 and made a dir. /usr/share
I mounted /usr/share_0 and an app`s. /usr/share on it and it works great.
But... It won`t unmount /usr/share, something`s using it. So it`s worthless.
If it could remount, that would probably work even with the mount busy.
And doing this trashed my internet setup, running the wizard fixed it.
Probably what was keeping it from unmounting, it could be fixed maybe.
But trying to repair all of the possible problems becomes a nightmare.

This is why I really want multi. link, mounts are dicey and more complex.
A link is about as small a resource as a FS has. No mount or unmount.
A multi. link would do exactly the same thing without all the problems.
Though it would only write to the first item in it`s list, no distribution.
For my needs this wouldn`t matter as I only need to read /usr/share .
Using: ln -sT the -T option writes a link over an old one while in use.
So this allows rearranging multi. link`s branches on the fly.

I`ll look at using aufs, even though it`s massive overkill for my needs.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum