From: Tomas M <tomas@slax.org>
To: linux-fsdevel@vger.kernel.org
Subject: Re: [RFC 1/2] AUFS: merging/stacking several filesystems
Date: Wed, 02 Apr 2008 17:11:19 +0200 [thread overview]
Message-ID: <47F3A217.1050003@slax.org> (raw)
In-Reply-To: <7016.1207113135@jrobl>
Hi all.
I am happy to see AuFS author in this list, and I hope there will be some people who review the design and post own comments and ideas, in order to make AuFS even better. :) 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 :)
That's all from me :)
Thanks
Tomas M
slax.org
next prev parent reply other threads:[~2008-04-02 15:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-02 5:12 [RFC 1/2] AUFS: merging/stacking several filesystems hooanon05
2008-04-02 15:11 ` Tomas M [this message]
2008-04-03 6:56 ` hooanon05
2008-04-03 6:53 ` hooanon05
2008-04-03 6:58 ` [RFC 2/2] " hooanon05
2008-05-12 4:43 ` hooanon05
2008-05-12 4:54 ` Andrew Morton
2008-05-16 14:20 ` hooanon05
2008-05-16 14:36 ` hooanon05
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47F3A217.1050003@slax.org \
--to=tomas@slax.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).