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 with 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
2.5.x as well, last one I've found in the mailing list was from 27th
of April 2011 ... 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 and when the error hapens, it's really
bad for the union (usually whole computer freezes). You won't see
anything like that in AuFS. Guess why Slax, knoppix and
hundreds of other projects switched to AuFS :)