[Automated-testing] Exporting an OverlayFS as NFS

[Attie Grande]

Hi Kieran,

It's perhaps not quite inline with your current setup, but ZFS would
work really well for this too.
You'd be able to populate, snapshot and update your 'plain' rootfs.
Subsequently, when booting a new session you'd be able to pick a
snapshot, clone it to a new filesystem and share it via NFS.
ZFS would manage all of the underlying storage, so usage would be low
if you don't change much (as per overlayfs).
Additionally I believe that ZFS can manage NFS shares automatically,
potentially reducing the administration - though I can't comment on
this more at the moment.

In my mind, ZFS is a no brainer for many other reasons as well (easy &
fast backups, frequent snapshots of working directories, resilient
storage, etc).

/zfs-plug

Attie

On 16 February 2018 at 09:23, Kieran Bingham <kbingham at kernel.org> wrote:
> Hi Farmers:
>
> In the recent LWN article: https://lwn.net/Articles/746791/ there is an excerpt
> highlighting that Overlay file systems can now (or will soon) export over NFS...
>
> I've been waiting for this for a long time...:
>
> ================================================================================
> Filesystems and block I/O
>
>     Overlay filesystems using overlayfs can now be exported via NFS. Enabling
> this functionality changes some overlayfs behavior and can create a filesystem
> that is not backward compatible; see the documentation in (this commit [0]) and
> (this commit [1]) for details.
>
> [0] https://git.kernel.org/linus/f168f1098dd9038daaf9f7be5f81cdea4985886a
> [1] https://git.kernel.org/linus/a01f64b5c06ca1130b0b72ceb5e2a25e4d37ab08
> ================================================================================
> (Thanks to Geert for highlighting this article to me)
>
> Looks like more detail available at : https://lwn.net/Articles/736677/ too.
>
>
> We've had a recent thread looking at SD card mux devices - but how many of us
> use NFS as our root for our board farms?
>
> The LWN topic excites me - because now I see a way towards having 'cheap'
> individual copies of a root filesystem for every *boot session* of a board.
>
>
> My vision here is that 'the farm controller', before powering up a board could
> prepare a fresh 'filesystem' by using a base (like a docker image), and creating
> a new location for the overlay to be handled. This unique overlay would then be
> passed as the NFS-Root.
>
> This then leaves the option of either keeping the filesystem state changes (only
> files modified, or tests files created) after a test has run, or simply
> discarding all changes if it was a disposable run.
>
> A first implementation of using this could be quite basic:
>   Create new mount point $NFS_NEW
>   Mount overlay from base at $NFS_NEW
>   Boot $BOARD @ $NFS_NEW
>
>
> But I could imagine features creeping in to an extent that the base filesystem
> could be handled like docker images (maybe we could even use the docker
> infrastructure to share rootfs base images):
>
>   farm-root pull arm-minimal
>
> Want to boot a full X environment? Prebuilt userspace?
>
>   farm-root pull ubuntu-arm:18.04
>
> (I now can't get it out of my head that the tool would obviously be called
> tractor: 'tractor pull ubuntu-arm:latest')
>
>
> Only really posting this to raise awareness of what I think is a very useful
> feature coming to us in v4.16 - and perhaps raise some discussion on desired
> features - or perhaps to discover that no one really uses NFS root anymore;
> because 96boards didn't put an Ethernet connector on the design.
>
>
> I think there's certainly scope to build some useful tools on top of NFS
> exported overlays though.
>
>
> Regards
> --
> Kieran
> --
> _______________________________________________
> automated-testing mailing list
> automated-testing at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/automated-testing