Date: Thu, 21 Apr 2011 17:13:23 +0900 From: Daichi GOTO <daichi@freebsd.org> To: Alex Zimnitsky <aavzz@yandex.ru> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: RFC: unionfs multiple mounts, cross mounts and recursive mounts limits and manegement feature Message-ID: <20110421171323.d554000d.daichi@freebsd.org> In-Reply-To: <1303369410.2152.21.camel@localhost> References: <20110421144947.b887081e.daichi@freebsd.org> <1303369410.2152.21.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Apr 2011 11:03:30 +0400 Alex Zimnitsky <aavzz@yandex.ru> wrote: > On Thu, 2011-04-21 at 14:49 +0900, Daichi GOTO wrote: > > > It is adjustable with sysctl value 'vfs.unionfs.recursive_limit' as > > multiple mounts limits. The default value is 1 and it means two-layered ok. > > Max value of 'vfs.unionfs.recursive_limit' is 8, it is heuristic value. > > I couldn't get a system panic unless 'vfs.unionfs.recursive_limit' is over 8. > > > > Hmm, 8 is not enough for me, i need more :) > > On the other hand, why do we need recursion in unionfs_statfs > at all? IMHO recursion in kernel is evil because it has a potencial > of resource exhaustion. > > This recursion in unionfs_statfs is used to gather statistic (some of > which is faked according to comments in the procedure) > > why not replace recursion with cycle? (I'm not skilled enough do do > that :) Exactly. It is one of possible plans to reduce kernel stack consumption except rewriting all relative recursive code into loop treatment is slow work to complete. Rewritten into loop treatment is the next step for our unionfs implementation ;) If rewritten completed, eventually we need some general fs-to-fs communication framework to detect situation comprehensively and prevent kernel stack consumption by multiple mounts of the combination of unionfs and loopback filesystem (especially for nullfs at this time). At this moment, there is no way to communitate with other loopback filesystem from unionfs, so unionfs cannot detect kernel stack consumption situation and prevent a system panic. In follow situation, unionfs cannot detect situation comprehensively and it could lead a system panic by exceeding kernel stack consumption. unionsf -> nullfs -> unionfs -> nullfs -> unionfs -> nullfs ... > and a feature request: > it would be great if it was possible to umount one of multiple unionfs: > > mount -t unionfs /var/ftpdata1 /var/ftp > mount -t unionfs /var/ftpdata2 /var/ftp > > how to unmount /var/ftpdata1 only? I understand how you feel. It is possible to implement. Apparently intermediate unionfs unmount feature is curious and convenience. To implement intermediate unionfs unmount, first we should discuss and define how treats "whiteout" of intermediate unionfs. Got any ideas? -- Daichi GOTO
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110421171323.d554000d.daichi>