Skip site navigation (1)Skip section navigation (2)
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>