Return bind_mounts option back.

[kvaps]

Hello, I use LTSP for the building farm of computing nodes

First, I forced to use NFS instead NBD, because NBD is very bad work with high-availability configuration.

Second, I forced to use bind_mounts method, because overlayfs
Second, I was forced to use bind_mounts method, because overlayfs for the time being can not provide the same stability as nfs+tmpfs.

It stores the states of the files, this is a problem if the node tries to access the file at the time that server is unavailable. And even if the server is available again, this file will remain unavailable unlike stateless NFSv3 and tmpfs.

So I consider it necessary to return this function to the code. This is my code:
https://github.com/kvaps/ltsp/compare/master...feature_bindmounts

It allows to use option `LTSP_ROOT_WRITE_METHOD=bind_mounts" if you want to use bind_mounts instead overlayfs.

This additional options will be returned back:

 - LTSP_RW_DIRS
 - LTSP_RW_DIRS_EXTRA
 - LTSP_COPY_DIRS
 - LTSP_COPY_DIRS_EXTRA
 - LTSP_BINDFILES
 - LTSP_BINDFILES_EXTRA

It fits well with #1680490 please review it too.

[Alkis Georgopoulos (alkisg)]

Sorry, but bind mounts are quite difficult to maintain properly. The LTSP initscripts and the client boot process in general write in too many places to properly keep track of them.

You can either maintain your patches locally, or you could send bug reports and patches for the overlayfs stability issues that you mention upstream to the kernel.
(And there's also a chance that you might convince some other LTSP developer to bring them back, but I doubt it.)

[kvaps (kvapss)]

No problem, I implemented it for me foremost.
Good idea I will create feature request in overlayfs bug tracker.
Thanks!

[Vagrant Cascadian (vagrantc)]

On 2017-04-06, kvaps wrote:
> Hello, I use LTSP for the building farm of computing nodes

Very interesting! Always like to hear about unconventional uses of LTSP.

> First, I forced to use NFS instead NBD, because NBD is very bad work
> with high-availability configuration.

Does AoE fare any better than NBD? There may be other methods than can
export a disk image over the network worth exploring over NFS's method
of exporting the files directly.

I've also had success using NFS to mount a loopback filesystem image
over with overlayfs+tmpfs, which might provide enough of the stability
you're looking for. It also provided better read performance than using
NFS to read the individual files. To use it, you need to specify
ltsploop=/path/to/image (relative the the NFS mount) at the bootprompt.

> Second, I was forced to use bind_mounts method, because overlayfs for
> the time being can not provide the same stability as nfs+tmpfs.

I switched the default in Debian away from NFS due to incompatibilities
with "overlay" fs in mainline linux 4+. There is also "overlayfs" which
was an out-of-tree module shipped with Ubuntu kernels for some years.

There is an "aufs-dkms" package in Debian Stretch. For several years
Debian used NFS+aufs+tmpfs as the default LTSP rootfs. I've been meaning
to see if this would work for NFS with LTSP and recent kernels, but
haven't had a chance to look into it yet.

> It allows to use option `LTSP_ROOT_WRITE_METHOD=bind_mounts" if you want
> to use bind_mounts instead overlayfs.
>
> This additional options will be returned back:
>
> - LTSP_RW_DIRS
> - LTSP_RW_DIRS_EXTRA
> - LTSP_COPY_DIRS
> - LTSP_COPY_DIRS_EXTRA
> - LTSP_BINDFILES
> - LTSP_BINDFILES_EXTRA

The burden of maintaining these features was the primary reason they
were removed (and apparently not completely removed); there were too
many things to keep track of in the code, too many paths that changed
over time, and the various union-fs approaches were largely in working
order, although unfortunately we've had some regressions with "overlay"
fs.

Hopefully either the "aufs-dkms" or "ltsploop" methods will meet your
needs well enough.

live well,
  vagrant

[kvaps (kvapss)]

Hello,
Thanks for your message!

>Always like to hear about unconventional uses of LTSP.
I think I will write about this solution later more deatil.

I not tested AoE, but NFSv3 suits me all, because nodes have readonly root and rarely accessed files from it.
In addition, I can make some minor changes to the root image and there is no need to restart the nodes after each change.

Good idea about loopback device over nfs :)

I wanted to try aufs, but did not find an easy way to do it.
Do you know, can aufs track changes at a higher level?
If no, it will not solve my problem, unfortunately.

I described this overlayfs bug and feature request to kernel bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=195271
https://bugzilla.kernel.org/show_bug.cgi?id=195273

I hope this will be resolved someday.

Thank you!

[kvaps (kvapss)]

UPD: added new directories