Date: Sun, 26 Sep 1999 14:05:16 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: current@freebsd.org Subject: HEADS UP, unionfs commit! Message-ID: <199909262105.OAA69583@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
A new unionfs has been committed. It fixes a whole lot of things,
but due to the complexity of the commit people should consider
unionfs to be unstable and under test. I will say, though, that
unionfs was terribly unstable before the commit and there is very
little that I could have done to actually make it worse :-)
There is an interesting story behind this commit. I had actually tried
to fix unionfs around a month ago, believing it would be relatively
simple. After several days of hacking I was no closer to making things
work better and gave up. This time around I approached unionfs from
the "everything must be broken" point of view and went through the
whole source with a fine toothed comb, rewriting and commenting much of
it .
My eventual goal is to be able to mount unionfs on / and have it
work so well as to be transparent. It's always nice to have an
unattainable goal (consider what unionfs would have to do if you
renamed a backing store directory, for example!).
My near-term goal is to be able to use unionfs for diskless
configurations, with read-only NFS mounts as backing store and
swap-backed VN based filesystems as fronting store. The idea
is to make the diskless workstation work exactly like a normal
server except that you lose everything when you reboot.
In anycase, this is a rough but still relatively complete commit.
unionfs is being actively worked on at the moment, and Tor is working
on nullfs.
The most common bug still probably in unionfs is a deadlock that may
lockup the processes using unionfs, but hopefully will not effect
processes not using unionfs. Warning: if you have /usr/src mounted
with unionfs you cannot gdb -k your active system because gdb will
try to access the source files under /usr/src and lockup along with
the rest of the unionfs related processes :-)
-Matt
dillon 1999/09/26 13:52:42 PDT
Modified files:
sys/miscfs/union union.h union_subr.c union_vfsops.c
union_vnops.c
Log:
This is a major fixup of unionfs. At least 30 serious bugs have been
fixed (many due to changing semantics in other parts of the kernel and not
the original author's fault), including one critical one: unionfs could
cause UFS corruption in the fronting store due to calling VOP_OPEN for
writing without turning on vmio for the UFS vnode.
Most of the bugs were related to semantics changes in VOP calls, lock
ordering problems (causing deadlocks), improper handling of a read-only
backing store (such as an NFS mount), improper referencing and locking
of vnodes, not using real struct locks for vnode locking, not using
recursive locks when accessing the fronting store, and things like that.
New functionality has been added: unionfs now has mmap() support, but
only partially tested, and rename has been enhanced considerably.
There are still some things that unionfs cannot do. You cannot
rename a directory without confusing unionfs, and there are issues
with softlinks, hardlinks, and special files. unionfs mostly doesn't
understand them (and never did).
There are probably still panic situations, but hopefully no where near
as many as before this commit.
The unionfs in this commit has been tested overlayed on /usr/src
(backing /usr/src being a read-only NFS mount, fronting /usr/src being
a local filesystem). kernel builds have been tested, buildworld is
undergoing testing. More testing is necessary.
Revision Changes Path
1.15 +37 -10 src/sys/miscfs/union/union.h
1.40 +349 -197 src/sys/miscfs/union/union_subr.c
1.36 +58 -68 src/sys/miscfs/union/union_vfsops.c
1.64 +818 -588 src/sys/miscfs/union/union_vnops.c
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909262105.OAA69583>