On Friday 08 July 2011, 14:57:09 Miklos Szeredi wrote: > "Hans-Peter Jansen" <hpj@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
