[RFC PATCH 0/6] Union mount core rewrite v1
Valerie Aurora
pathname lookup code. For more info about union mounts, see:
http://valerieaurora.org/union/
The previous code had two important problems fixed in this series:
- On file open, is_unionized() grabs vfsmount lock and walks up the
mount tree even for non-union mounts.
- Pathname lookup required three cut-n-pasted versions of two complex
functions, one for each of cached/real/"hashed" lookups.
This rewrite reduces the additional cost of a non-union lookup in a
CONFIG_UNION_MOUNT kernel to either 1 or 2 mount flag tests (but adds
the requirement that file systems be unioned only at their root
directories). This rewrite implements lookup with one lookup_union()
function for all types of lookups.
This posted patch series includes only the union lookup, mount, and
readdir patches and not the relatively uncontroversial whiteout and
fallthru code. Rewrite of the in-kernel file copyup is next on my
todo list.
The entire patch set is against Viro's for-next branch, and available
at:
git://git.kernel.org/pub/scm/linux/kernel/git/val/linux-2.6.git
Branch no_copyup. Please review! Thanks,
-VAL
Jan Blunck (3):
union-mount: Introduce union_mount structure and basic operations
union-mount: Drive the union cache via dcache
union-mount: Call do_whiteout() on unlink and rmdir in unions
Valerie Aurora (3):
union-mount: Implement union lookup
union-mount: Support for mounting union mount file systems
union-mount: Copy up directory entries on first readdir()
fs/Kconfig | 13 +
fs/Makefile | 1 +
fs/dcache.c | 17 ++
fs/namei.c | 199 +++++++++++++++-
fs/namespace.c | 123 ++++++++++-
fs/readdir.c | 9 +
fs/union.c | 629 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/dcache.h | 28 +++
include/linux/mount.h | 3 +
include/linux/union.h | 74 ++++++
10 files changed, 1094 insertions(+), 2 deletions(-)
create mode 100644 fs/union.c
create mode 100644 include/linux/union.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Miklos Szeredi
> This is a major rewrite of parts of union mounts, in particular the
> pathname lookup code. For more info about union mounts, see:
>
> http://valerieaurora.org/union/
>
> The previous code had two important problems fixed in this series:
>
> - On file open, is_unionized() grabs vfsmount lock and walks up the
> mount tree even for non-union mounts.
>
> - Pathname lookup required three cut-n-pasted versions of two complex
> functions, one for each of cached/real/"hashed" lookups.
Looks much better :)
> This rewrite reduces the additional cost of a non-union lookup in a
> CONFIG_UNION_MOUNT kernel to either 1 or 2 mount flag tests (but adds
> the requirement that file systems be unioned only at their root
> directories). This rewrite implements lookup with one lookup_union()
> function for all types of lookups.
>
> This posted patch series includes only the union lookup, mount, and
> readdir patches and not the relatively uncontroversial whiteout and
> fallthru code.
Special inode/dentry flags (whiteout, fallthrough, opaque) are not
trivially the right solution:
- they are invisible from userspace, new APIs are necessary to manipulate them
- they are difficult to support on network filesystems
- they are not useful for anything other than union mounts/filesystems
Extended attributes are a more standard way to add such info to files.
Hard links would allow sharing a single inode for all whiteout entries
and one for all fallthrough entries.
Have these options been considered as an alternative?
Thanks,
Miklos
Valerie Aurora
> On Tue, 2 Mar 2010, Valerie Aurora wrote:
> > This is a major rewrite of parts of union mounts, in particular the
> > pathname lookup code. For more info about union mounts, see:
> >
> > http://valerieaurora.org/union/
> >
> > The previous code had two important problems fixed in this series:
> >
> > - On file open, is_unionized() grabs vfsmount lock and walks up the
> > mount tree even for non-union mounts.
> >
> > - Pathname lookup required three cut-n-pasted versions of two complex
> > functions, one for each of cached/real/"hashed" lookups.
>
> Looks much better :)
Thanks for the review. :)
> > This rewrite reduces the additional cost of a non-union lookup in a
> > CONFIG_UNION_MOUNT kernel to either 1 or 2 mount flag tests (but adds
> > the requirement that file systems be unioned only at their root
> > directories). This rewrite implements lookup with one lookup_union()
> > function for all types of lookups.
> >
> > This posted patch series includes only the union lookup, mount, and
> > readdir patches and not the relatively uncontroversial whiteout and
> > fallthru code.
>
> Special inode/dentry flags (whiteout, fallthrough, opaque) are not
> trivially the right solution:
>
> - they are invisible from userspace, new APIs are necessary to manipulate them
> - they are difficult to support on network filesystems
> - they are not useful for anything other than union mounts/filesystems
>
> Extended attributes are a more standard way to add such info to files.
> Hard links would allow sharing a single inode for all whiteout entries
> and one for all fallthrough entries.
>
> Have these options been considered as an alternative?
Thanks for bringing that up! We have considered them and aren't sure
what the best solution is - all the options, including our current
example implementations, have serious drawbacks. Fortunately, the
implementation of whiteouts, etc. is fairly separate from the main
body of union mount code. For example, I'm pretty sure you could
implement whiteouts, fallthrus, and opaque flags in ext2 as system
extended attributes or as hard links (or as crazy special symlinks)
without changing any other non-ext2 patches. We already switched once
from encoding whiteouts with reserved inode numbers in ext3 to
whiteouts as a new dentry type flag in ext2 and that didn't affect
other patches. In general, I am happy with whatever the maintainer of
the underlying file system prefers.
The advantage of the system extended attribute approach is that any
file system with xattrs also supports union mounts. It might be worth
implementing for that reason alone.
-VAL