Date: Fri, 01 Dec 2006 22:38:34 +0900 From: Daichi GOTO <daichi@freebsd.org> To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org, rodrigc@crodrigues.org Cc: daichi@freebsd.org, ozawa@ongs.co.jp Subject: [ANN] unionfs patchset-17 release, lock mechanism changed for robust working Message-ID: <4570305A.4010908@freebsd.org>
next in thread | raw e-mail | index | archive | help
Hi Guys!
It is my pleasure and honor to announce the availability of
the unionfs patchset-17. p17 have some significant improvements
around the lock mechanism for robust and stable working.
Patchset-17:
For 7-current
http://people.freebsd.org/~daichi/unionfs/unionfs-p17.diff
For 6.x
sorry, it is for current only.
Changes in unionfs-p17.diff
- Fs takes illegal access without lock of lower layer
vnode if the both upper/lower layers have both vnode.
To fix this problem, we change the lock mechanism to
get locks for both upper/lower layer always.
- Kernel gets a dead-lock easily within above
upper/lower-layer-always-lock-mechanism. To avoide
above dead-lock, we changed vfs_lookup.c. By that change,
it always locks vnodes parent first and children second.
You could see the same lock-order-control implementation
around cache_lookup.
- It takes the both open/close operations per kernel thread.
- It takes readdir-treat-status-management per kernel thread.
- It reopens vnode if needed when coping to upper layer on
advlock.
- mount_unionfs(8) changes option style fitting for fstab(5)
style. (by rodrigc)
- manual of mount_unionfs(8) was changed. (by rodrigc)
The documents of those unionfs patches:
http://people.freebsd.org/~daichi/unionfs/ (English)
http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese)
After release of p16, some folks gave us some panic reports that
indicate our implementations has a critical problem around the lock
mechanism.
After our long researches and discussions, we have tried to
re-implement our unionfs lock mechanism. And it is done :)
For unionfs lovers (including FreeSBIE developers, ports cluster
managers, heavy memory-fs users, or folks use unionfs), could you
try p17 please? If p17 solves that panics, we guess it is unionfs
merge time for current branch.
Thanks
P.S.
Current English document of web has some Japanese contents. We
need a translator ;-)
--
Daichi GOTO, http://people.freebsd.org/~daichi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4570305A.4010908>