Re: [Devil-Linux-discuss] DL configuration/Unionfs

[Dick M. <di...@li...>]

Heiko Zuerker wrote:

> Quoting Bruce Smith <bw...@ar...>:
> 
>>> both unionfs and aufs are std in Debian if you've got a deb desktop.
>> What's the difference between unionfs & aufs?  Does DL have aufs?
>> Which one should we use for this?
> 
> I don't know what the difference is. Aufs is not in DL right now.
> If aufs is really more stable and maybe better maintained, then we  
> should go for that one.

I don't know either.  The aufs people understandably advocate their offering 
enthusiastically. See below.

However I use Debian sid amd64 and I've not had unionfs working for a long while 
for one reason or another whereas aufs worked first time out of the box so I'm 
favourably disposed towards it.

Aufs claim their offering is smaller lighter, more reliable and better featured. 
  Since we're only going to use a basic part of the functionality I doubt it 
will make much difference.

> We also need to choose wisely, so we don't have to wait for a patch  
> for a new kernel for a couple of months.

unionfs says it is in Andrew Mortons patches but I think that's as near either 
are to being included in the kernel.

Dick

Why to use AuFS instead of unionfs:
-----------------------------------

I am an AuFS user for a long time and what I really appreciate
(from the user's point of view) is the following:

# AuFS supports writable branch balancing. That means, you can setup several 
partitions for writing and AuFS will split all new/modified files between them, 
based on free disk space, existence of parent directory, randomly, or combinations.


# AuFS supports huge amount of branches. I'm currently using hundreds of 
branches without just a small slowdown (which is obvious).


# AuFS provides a list of branches through /sys, which doesn't have the 
limitation like /proc/mounts. For that reason, it works correctly even with 
thousand of branches (while so much branches would break /proc/mounts at all).


# AuFS implements 'rr' branch mode, it means 'really-readonly'. This is really 
useful, particularly for ISO images or SquashFS filesystems as a brach, as AuFS 
doesn't need to re-lookup those filesystems. (You know, a readonly branch 'ro' 
can be modified from another place, eg. network, so there can occur a 'direct 
branch access' even for read-only directories and AuFS handles it correctly.)


# last, but not the least, AuFS is really stable in real world situations. I 
used unionfs in the past, but my second name for it was 'NULL POINTER 
DEREFERENCE'. I can see those errors still happening in latest unionfs as well, 
last one I've found is from 27th of May 2008 ... BUG: unable to handle kernel 
NULL pointer dereference. ... I have absolutely no idea what that means, but the 
same errors keep appearing in unionfs for years. You won't see anything like 
that in AuFS. Guess why knoppix and other projects switched to it :)

                                                            Tomas M
                                                            slax.org