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

[Miklos Szeredi]

"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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/