Apps :: unionfs blocking mc subshells

Quote

In any case, I'm going to continue using legacy, possibly until it is no longer supported. The only thing I'd really like to try with it is xfree/xorg, but even that is in a very distant plan to be made into uci.

I am still reading of the trials and tribulations of those who pursue unionfs/aufs even with 2.6 kernel and newer versions of these overlays and now another posixovl.

I too like and prefer my original concept (KISS) of self contained UCI. Perhaps I should generate a 2.6 kernel legacy edition. Can we go it alone with no overlays?

There are now other projects with similiar concepts to uci. Perhaps the chrooted builds of their self contained applications is worth a look.

I'd like to mention devicemapper. The LFS livecd is a great testing ground, because it really stresses the system with heavy compilations like gcc. They used unionfs before. And got several kernel panics.
Currently they use device-mapper's snapshot. I've looked into that technology, and it really works. I've gotten no kernel panics or any problems at all with my 5+ system builds with LFS livecd as a host.
It's very good for an overlay; especially when it was not meant for that use.

This is also the system I will use, if I ever get the thing started

I know maintaining support for legacy has been a pain for you Robert; perhaps Mikshaw's issue with mc retroactively justifies your efforts. How difficult is it to continue to provide a legacy boot option? I mean, what are the downsides incurred?

@Mikshaw: I'm not an mc man either. I suppose there is an mc support mail list where you might get some clue as to exactly what the issue is? There must be other systems running mc on top of unionfs.

Would seem perhaps extreme to throw out uniofs/aufs architecture altogether if legacy can switch it off.

Besides device-mapper I imagine fuse might also be used to provide a similar capability for self-contained apps, but I was told by someone who definitely would know that fuse is inefficient and slow.

Knoppix has been using aufs since 3.9 - how are they going with that?

Quote

Would seem perhaps extreme to throw out uniofs/aufs architecture altogether if legacy can switch it off.

Or make that a boot option to turn on unionfs and make "legacy" the default.

Quote

Knoppix has been using aufs since 3.9 - how are they going with that?

Unionfs is iffy on just about every implementation of it. Go through the FreeBSD changelogs and look how many times it's been added and removed. It's been re-implemented in 6.3, which for all I know means series of patches have been added to minimize some of the scary-frightening-proceed-with-caution warnings in the manpage.
Release note with brief notice of "new and improved" unionfs:
http://www.freebsd.org/releases/6.3R/announce.html

And from the manpage:

Quote

BUGS
THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET.

This code also needs an owner in order to be less dangerous - serious hackers can apply by sending mail to <hackers@FreeBSD.org> and announcing their intent to take it over.

Without whiteout support from the file system backing the upper layer, there is no way that delete and rename operations on lower layer objects can be done. EROFS is returned for this kind of operations along with any others which would make modifications to the lower layer, such as chmod(1).

Running find(1) over a union tree has the side-effect of creating a tree of shadow directories in the upper layer.

FreeBSD 6.2

The execution is flawed. I love the concept, though.

Running find over a union tree creates a hang for me..

Next Page...
original here.