This changeset introduces a fuse-overlayfs snapshot backend via https://github.com/AkihiroSuda/containerd-fuse-overlayfs, providing better performance and more efficient space usage than the native backend when fuse-overlayfs is available. It also includes associated README updates, and dependency updates resulting from the inclusion of the new module.
As part of the change, the auto backend now prefers fuse-overlayfs to the native backend when available. overlayfs is still preferred when Ubuntu kernel patches are in place. This seemed like the most reasonable behavior to me, even if it means some existing users who have auto-selected the native backend will silently "start over" with fresh state (e.g. containers/storage treats pre-existing vfs driver state in similar fashion during auto-selection). If that's a problem, perhaps we could add the new backend as a manual selection only, or auto-select backends based on existing state directories (more like the linked containers/storage example)?
This changeset introduces a
fuse-overlayfssnapshot backend via https://github.com/AkihiroSuda/containerd-fuse-overlayfs, providing better performance and more efficient space usage than thenativebackend when fuse-overlayfs is available. It also includes associated README updates, and dependency updates resulting from the inclusion of the new module.As part of the change, the
autobackend now prefersfuse-overlayfsto thenativebackend when available.overlayfsis still preferred when Ubuntu kernel patches are in place. This seemed like the most reasonable behavior to me, even if it means some existing users who have auto-selected thenativebackend will silently "start over" with fresh state (e.g. containers/storage treats pre-existingvfsdriver state in similar fashion during auto-selection). If that's a problem, perhaps we could add the new backend as a manual selection only, or auto-select backends based on existing state directories (more like the linked containers/storage example)?