On Mon, Feb 27, 2017 at 2:40 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > It may be easier if you can argue for a use case which does have > defined behavior, > for example, lower fs has some directory subtrees that are not > modified via overlayfs > and only modified directry via lower fs. > I think this *may* result in defined behavior over lower remote fs, > but can't tell for sure. > Anyway, you will have to argue why such a setup is useful. My use case is actually one that involves very little (but necessary) writes to the overlayfs, and the vast majority of changes happen directly to the lower fs. I maintain cluster management software that has been used on some of the largest clusters in the world. The premise is to network boot and mount a shared NFS root on an arbitrarily large number of cluster nodes. It has always been an annoyance to have to find the little bits and pieces in the OS (think of a full RHEL/CentOS distro) that require the ability to write somewhere and so we've always had to play silly tricks to get around that. Using a ram overlay as the upper allows these minor writes to happen transparently and save end users massive amounts of time having to track down and handle each one individually. The behavior I've noted so far from this patch seems to be very well defined and follows the rule of least surprise (at least for me). I can change files/directories in the shared root and the changes are instantly visible to all clients. If a file/directory has been copied up on the client that change takes precedence over changes in the lower. Deletes work as expected. I haven't found a downside yet. In fact I've bundled a release of my software that configures this mode of operation as on option. The given patch is included with that release, but it would be 1000 times cleaner as a stock kernel module parameter with no patches required. -JE
