HowTo use chroot for setting current shell`s "/" ?

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#16 Post by sunburnt »

### FORGET ALL THIS... It`s much too complex and isn`t a solution.


### I finally found what I`ve been looking for.

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...).

Code: Select all

@@@@ To mount:
sh-4.1# mhddfs /tmp/0,/tmp/1,/root/docs/0 /tmp/7/ -o allow_other

mhddfs: directory '/tmp/0' added to list
mhddfs: directory '/tmp/1' added to list
mhddfs: directory '/root/docs/0' added to list
mhddfs: mount to: /tmp/7/
mhddfs: move size limit 4294967296 bytes

@@@@ To unmount:
sh-4.1# fusermount -u /tmp/7

@@@@ This allows all users access. Not just mount creator:
 -o allow_other
There are a few other utilities like it, most are for merging HD partitions.

This will make the difference in easy to make and use app. packages.
And also for rearranging the Linux file system for a new type of O.S.
Attachments
mhddfs_0.1.28-1_i386.zip
From Ubuntu Lucid, so good for most Puppies I think.
Puppy Lucid528 has everything else that`s needed ( Fuse ).
(24.13 KiB) Downloaded 323 times
Last edited by sunburnt on Wed 20 Jun 2012, 08:40, edited 6 times in total.

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#17 Post by disciple »

I was looking at that the other day, but I couldn't quite figure out the advantage over unionfs...
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#18 Post by sunburnt »

Simpler is the main thing I see... So fewer problems ( white-out files ).

It seems better suited to combining small parts of the dir. tree than a union.

And with virtually no system usage, you can use it many many times!

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#19 Post by disciple »

How does it enable "deleting" if it doesn't use white out files?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#20 Post by Karl Godt »

sunburnt wrote:Simpler is the main thing I see... So fewer problems ( white-out files ).

It seems better suited to combining small parts of the dir. tree than a union.

And with virtually no system usage, you can use it many many times!
FWIW : I had my first Puppy crash since i upgraded to more recent hardware ( MWDMA 4GB HDD to DMA-100/133 HDD ) with racy-5.2.2 which uses unionfs : X showed console with X-cursor and panic was something with unionfs (flash pendrive PUPMODE=13) .

Racy-5.3 again uses aufs .
I used Unionfs in the kernels in Wary and Racy 5.2.2, and I thought that all was well.
Unionfs letting us down?

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#21 Post by jamesbond »

Good find, sunburnt!
disciple wrote:How does it enable "deleting" if it doesn't use white out files?
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 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#22 Post by jpeps »

sunburnt wrote:
It`s called "mhddfs", it uses Fuse and is simple to use.
Looks like a big performance drain:


"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:"

http://hardforum.com/archive/index.php/t-1501421.html

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#23 Post by disciple »

And
If there's something that is bloated, slow and sub-optimal its FUSE.
:)

That's what I suspected about FUSE, but I figured sunburnt must have had something on which to base that "virtually no system usage" claim.

Now this sounds interesting:
Personally i would feel much more at home with ZFS; it does create a single volume out of your multiple drives (which is what you want) but doesn't rely on any userland-drivers like FUSE does.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#24 Post by amigo »

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.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#25 Post by Karl Godt »

I got curious and compiled the fuse stuff with one or two dependencies for the devel files and it put me a /etc/init.d/fuse file .

Seems that it mounts

fusectl on "/sys/fs/fuse/connections" type fusectl (rw,relatime)

And when i shutdown yesterday it seemed that unmounting

"/sys/fs/fuse/connections"

automatically unmounted ntfs partitions mounted with ntfd-3g .

At least the output of my rc.shutdown.local.start script told me, that in the for loop all of a sudden /dev/sda7 had been invalid ...


It seems bit similar to killing ntfs-3g leaving the partition ("dirty") unmounted .

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#26 Post by sunburnt »

Mhddfs was intended to union partitions, which are just dirs. My use.

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, 21:36, edited 1 time in total.

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#27 Post by Karl Godt »

sunburnt wrote:Mhddfs was intended to union partitions, which are just dirs. My use.
This seems apparently how fuse is working. fuse has a lot of meanings using dict fuse, i guess the string
"2. To unite or blend, as if melted together.
[1913 Webster]"

would fit a mount.fuse description best .

So using fuse i would need to mount partitions first "normally" and then

mount.fuse /mnt/sdb1 /mnt/new
mount.fuse /mnt/sdb2 /mnt/new

so these two partitions can be merged
?

User avatar
vovchik
Posts: 1507
Joined: Tue 24 Oct 2006, 00:02
Location: Ukraine

#28 Post by vovchik »

Dear Terry (aka sunburnt),

I think that is a really nice find. I now have to think of how I can use this facility intelligently. Many ideas will come to mind in time. If you have some already, please post.

With thanks and kind regards,
vovchik

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#29 Post by sunburnt »

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, 05:22, edited 2 times in total.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#30 Post by sunburnt »

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.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#31 Post by sunburnt »

# Last Update:

As little as I like the mess of links, I dislike the over head and complexity of unions even more.

I came up with a setup that only requires 4 links for each app.
So for 20 apps. that would be 80 links, not bad all in all.
Especially when you consider, it`s the links or the real files.

However... Only 4 Multi. Links would be needed to do the same job!
It shows in this one aspect only, how capable the idea is...
.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#32 Post by amigo »

Your concept of a multi-link is still flawed. There simply is no such thing. How can you have an arrow that points to four places -how should an application know which direction you really want? The union mount comcept is the only thing which resembles what you describe.

It's true that you really only have LD_PRELOAD, LD_LIBRARY_PATH and PATH to setup paths to libs and bins. They do not help you for config files and shared files. The way to resolve it for AppDirs is to simply compile them using --prefix=$APP_DIR, where APP_DIR is the specific directory where the application is located. This will usually insure that applications can find their config files, shared files and bins/libs all under one directory.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#33 Post by sunburnt »

Hi amigo; The multi. link is just not as capable as a union, and that`s all.
But then... That`s the idea also, that it be lighter and simplier. Just a link.
There was no sym link for a while also, and no union, and how about X?
All new ideas start somewhere, right? Einstein`s 1 part inspiration, etc.

A link currently will hold any text you put in it, but the kernel can`t use it.
Try this: ln -s /1/2/3:/4/5/6:/7/8/9 testLink
Hover over in ROX and it shows the path`s there, but it`s dead of course.

A hard link is for files, a sym link for both, and a multi. link for dirs. only.
The kernel needs code to thread it`s path parsing with the link handler.
It would see the link as one space of all 3 paths, for reading that is.

For writing it would only write to the first path, no distributing like mhddfs.
Like $PATH it will only see and act upon the first of duplicates in it`s path.
But understand... For what needs to be done here, only reading is needed.
You don`t need to write or delete anything, no changes in general.

So to say it`s flawed would be to say much of the rest of Linux is flawed.


Yes I know about --prefix (Path), but it does not work all the time.
The program has to be written that way for it to work, most are fortunately.
And writing to elf binaries to fix the path didn`t work all the time either.
The chroot idea just got too complex, need a simple silver bullet that works.

The idea to use the many links is messy, but it should work all the time.
Any other places deps. are? Besides /local/share/, /root, and /opt.

Oh... And in my example of 20 apps. the 4 multi. links point to 20 places. :wink:

Post Reply