From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: Unionmount status? Date: Fri, 15 Apr 2011 12:31:45 -0400 Message-ID: <4DA872F1.8080101@gmail.com> References: <4DA4B6A8.7030804@gmail.com> <4DA5DCB8.3040101@gmail.com> <4DA5F569.9020309@gmail.com> <1302756608.2854.10.camel@perseus.themaw.net> <4DA6F4E2.1060005@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Miklos Szeredi , Christoph Hellwig , Ian Kent , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , Jeff Moyer To: Michal Suchanek Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 04/14/2011 10:54 AM, Michal Suchanek wrote: > On 14 April 2011 15:21, Ric Wheeler wrote: >> On 04/14/2011 05:40 AM, Miklos Szeredi wrote: >>> On Thu, Apr 14, 2011 at 11:32 AM, Michal Suchanek >>> wrote: >>>> I guess overlayfs includes the better part of unionmount and achieves >>>> similar level of functionality in much smaller code size and is >>>> actively developed. >>>> >>>> This might make it the best candidate for inclusion so far. >>>> >>>> It does not (yet?) support NFS which is one of the options commonly >>>> used with union solutions, though. >>> NFS is supported as a lower (read-only) layer, but not as an upper >>> (read-write) layer. >>> >>> Thanks, >>> Miklos >> I am not that concerned with the state of Val's repo, her intention was to >> hand off the project cleanly to others and have them drive the code (that >> hand off was the posting of the patch set). Several people (Ian, David >> Howells and Al Viro) had been involved with union mounts recently, so we do >> have reasonable candidates for a hand off. >> >> One of the concerns with unionfs is the duplication of data. Union mounts >> avoids this with that implementation. That might make unionfs more of a >> burden for very large file systems, but probably not a concern for many use >> cases. > Just to make things clear, what is a very large filesystem? > > A heavily compressed DVD image? > > Tens or hundreds of gigabytes? Terabytes? > > Hundreds, thousands or hundreds of thousands of inodes? > > Or is testing required to determine at what size the performance > becomes unacceptable? > > Thanks > > Michal Very large in the number of inodes more so than fs size... Ric