From: "J. R. Okajima" <hooanon05g@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Amir Goldstein <amir73il@gmail.com>, Eryu Guan <eguan@redhat.com>,
fstests <fstests@vger.kernel.org>,
linux-unionfs@vger.kernel.org
Subject: Re: [PATCH] overlay: stress test changes to top and bottom layers simultaneously
Date: Sat, 10 Dec 2016 02:30:03 +0900 [thread overview]
Message-ID: <14481.1481304603@jrobl> (raw)
In-Reply-To: <20161208141639.tzblbtwlqyzhckrm@thunk.org>
"Theodore Ts'o":
> Since the use of unionfs is deprecated, I didn't bother to test it,
> although I could if someone was really curious whether it would BUG or
> not. (Given that both wrapfs and sdcardfs did BUG, I'm pretty that
> unionfs, as a wrapfs derivitive, also would go down in flames. It
> might also be fun, since there are some Ubuntu Docker users using
> AUFS, to see if AUFS --- as another wrapfs derivitive --- might also
> be succeptible.)
If you mean that aufs is based upon wrapfs or unionfs, then it is not
true. aufs1 was based upon unionfs acutally, but aufs2 and later are
totally re-written and added many new approaches and ideas.
Some of those new approaches are opposite of overlayfs' ones.
For example,
- overlayfs added d_real_inode(), lock_inode() and others into VFS. They
aim to get the layers' inode via overlayfs' dentry. Honestly speaking
I am afraid they confuse people who were calling d_inode().
- aufs aims to be an ordinary filesystem against VFS, and VFS uses its
dentry as usual. Acessing the layers' inode is totally hidden within
aufs and VFS doesn't care about it.
One exception aufs modifies VFS (actually MM module) is vma_struct
which contains a file pointer to point the file mmapped. Aufs adds
another file pointer to show the path under procfs.
Also aufs allows users to modify the files on the layers direcly,
ie. bypassing aufs. Next time when user accesses those files, aufs
re-validates it and detect the changes. Additioanlly aufs has
another option to discard the caches when the files on the layers
changed directly.
J. R. Okajima
next prev parent reply other threads:[~2016-12-09 17:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 3:58 [PATCH] overlay: stress test changes to top and bottom layers simultaneously Theodore Ts'o
2016-12-08 4:37 ` Eryu Guan
2016-12-08 6:37 ` Amir Goldstein
2016-12-08 14:16 ` Theodore Ts'o
2016-12-09 17:30 ` J. R. Okajima [this message]
2016-12-08 14:27 ` Amir Goldstein
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=14481.1481304603@jrobl \
--to=hooanon05g@gmail.com \
--cc=amir73il@gmail.com \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.