Re: [PATCH 0/7] overlay filesystem: request for inclusion

["Hans-Peter Jansen" <hpj@urpla.net>]

On Friday 08 July 2011, 14:57:09 Miklos Szeredi wrote:
> "Hans-Peter Jansen" <hpj@urpla.net> writes:
> > All kodos to you, Miklos. While I'm still missing a major feature
> > from overlayfs that is a NFS as upper layer, it provides a fairly
> > good start. A commitment from you, that such an extension is
> > considered for inclusion - given, that it appears one day - is
> > appreciated. Also, since xattr support is available for NFS,
>
> AFAIK development of generic xattr support on NFS stopped some time
> ago.
>
> > it would be nice to outline, what is missing for such an
> > implementation from overlayfs's POV.
>
> Allow using namspace polluting xattr replacements, such as aufs is
> doing.
>
> But why?  Why is it better to do the overlaying on the client instead
> of the server?

Exporting layered filesystems via NFS suffered from many problems 
traditionally, because that permuted NFS export issues of the server FS 
in use (say xfs) with FS layering issues. Since I'm doing diskless 
computing for more then two decades now, I always persued for lowering 
complexity, and/or localize it. Layering on the client is done with the 
latter in mind. While the basic concept of layered FS is sound, 
especially, things like mmapping and splicing cause hard to track down 
and problems, that are even harder to solve properly. 

Do you have experiences with NFS exported overlay FSs already? If that 
proves stable, does scale, and a client is able to survive a server 
reboot, layering on the server is a sexy approach of course (I hate to 
being forced to maintain my own kernel flavors for diskless clients, 
while I love to track the Linux kernel progress in general..).

Does a openSUSE build service kernel project exist with overlayfs 
included? If I read the patch correctly, it's not possible to just bake 
overlayfs as a standalone KMP ATM.

Let's-get-it-in-for-3.1-please'ly yours,
Pete