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

[Bruce S. <bw...@ar...>]

[moving this thread to the develop list] 

I went to the aufs web site and I can't even find a tarball to download.
The only way I can find to download the source is to check out from cvs.
Does anyone know of a easier way to download aufs?

UnionFS has tarballs for all the latest kernels, including the RC
kernels.  That method would much easier to maintain in DL.

 - BS


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