"Hans-Peter Jansen" <hpj@xxxxxxxxx> writes: > On Friday 08 July 2011, 14:57:09 Miklos Szeredi wrote: >> 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..). Well, you are right, exporting an overlay has its own complexities. Abstracting the whiteout/opaque flags behind an implementation that can use xattr or plain files sounds pretty easy to do in comparison. I'll look into that. But this is again a feature that needs to go in a later. > 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. No, it needs small VFS modifications, so a standalone module doesn't work. Thanks, Miklos -- 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
