nspawn: add fallback top normal copy/reflink when we cannot btrfs snapshot

Given that other file systems (notably: xfs) support reflinks these days, let's
extend the file system snapshotting logic to fall back to plan copies or
reflinks when full btrfs subvolume snapshots are not available.

This essentially makes "systemd-nspawn --ephemeral" and "systemd-nspawn
--template=" available on non-btrfs subvolumes. Of course, both operations will
still be slower on non-btrfs than on btrfs (simply because reflinking each file
individually in a directory tree is still slower than doing this in one step
for a whole subvolume), but it's probably good enough for many cases, and we
should provide the users with the tools, they have to figure out what's good
for them.

Note that "machinectl clone" already had a fallback like this in place, this
patch generalizes this, and adds similar support to our other cases.

2 files changed, 15 insertions, 27 deletions

diff --git a/man/machinectl.xml b/man/machinectl.xml
index 5a6ec294d2..81192417d8 100644
--- a/man/machinectl.xml
+++ b/man/machinectl.xml
@@ -599,8 +599,8 @@
         <listitem><para>Clones a container or VM image. The arguments specify the name of the image to clone and the
         name of the newly cloned image. Note that plain directory container images are cloned into btrfs subvolume
         images with this command, if the underlying file system supports this.  Note that cloning a container or VM
-        image is optimized for btrfs file systems, and might not be efficient on others, due to file system
-        limitations.</para>
+        image is optimized for file systems that support copy-on-write, and might not be efficient on others, due to
+        file system limitations.</para>
 
         <para>Note that this command leaves host name, machine ID and
         all other settings that could identify the instance
@@ -910,7 +910,7 @@
     <filename>/var/lib/machines/</filename> to make them available for
     control with <command>machinectl</command>.</para>
 
-    <para>Note that many image operations are only supported,
+    <para>Note that some image operations are only supported,
     efficient or atomic on btrfs file systems. Due to this, if the
     <command>pull-tar</command>, <command>pull-raw</command>,
     <command>import-tar</command>, <command>import-raw</command> and
diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index c29542236d..dbbf9890c8 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -181,25 +181,15 @@
       <varlistentry>
         <term><option>--template=</option></term>
 
-        <listitem><para>Directory or <literal>btrfs</literal>
-        subvolume to use as template for the container's root
-        directory. If this is specified and the container's root
-        directory (as configured by <option>--directory=</option>)
-        does not yet exist it is created as <literal>btrfs</literal>
-        subvolume and populated from this template tree. Ideally, the
-        specified template path refers to the root of a
-        <literal>btrfs</literal> subvolume, in which case a simple
-        copy-on-write snapshot is taken, and populating the root
-        directory is instant. If the specified template path does not
-        refer to the root of a <literal>btrfs</literal> subvolume (or
-        not even to a <literal>btrfs</literal> file system at all),
-        the tree is copied, which can be substantially more
-        time-consuming. Note that if this option is used the
-        container's root directory (in contrast to the template
-        directory!) must be located on a <literal>btrfs</literal> file
-        system, so that the <literal>btrfs</literal> subvolume may be
-        created. May not be specified together with
-        <option>--image=</option> or
+        <listitem><para>Directory or <literal>btrfs</literal> subvolume to use as template for the container's root
+        directory. If this is specified and the container's root directory (as configured by
+        <option>--directory=</option>) does not yet exist it is created as <literal>btrfs</literal> snapshot (if
+        supported) or plain directory (otherwise) and populated from this template tree. Ideally, the specified
+        template path refers to the root of a <literal>btrfs</literal> subvolume, in which case a simple copy-on-write
+        snapshot is taken, and populating the root directory is instant. If the specified template path does not refer
+        to the root of a <literal>btrfs</literal> subvolume (or not even to a <literal>btrfs</literal> file system at
+        all), the tree is copied (though possibly in a copy-on-write scheme — if the file system supports that), which
+        can be substantially more time-consuming. May not be specified together with <option>--image=</option> or
         <option>--ephemeral</option>.</para>
 
         <para>Note that this switch leaves host name, machine ID and
@@ -1052,14 +1042,12 @@
     </example>
 
     <example>
-      <title>Boot into an ephemeral <literal>btrfs</literal> snapshot of the host system</title>
+      <title>Boot into an ephemeral snapshot of the host system</title>
 
       <programlisting># systemd-nspawn -D / -xb</programlisting>
 
-      <para>This runs a copy of the host system in a
-      <literal>btrfs</literal> snapshot which is removed immediately
-      when the container exits. All file system changes made during
-      runtime will be lost on shutdown, hence.</para>
+      <para>This runs a copy of the host system in a snapshot which is removed immediately when the container
+      exits. All file system changes made during runtime will be lost on shutdown, hence.</para>
     </example>
 
     <example>