[slx-dmsetup] reintroduce linear 1:1 mapping of scratch device

Using the physical partition of NVMe directly led to errors when
creating the pool. As a workaround, we can "wrap" it in a linear target
of the same size. While this is superfluous in general, this works
around that specific problem. We can remove this workaround when we have
a better idea on how to fix pool creation on NVMes.

1 files changed, 13 insertions, 1 deletions

diff --git a/modules.d/slx-dmsetup/scripts/dmsetup-slx-device b/modules.d/slx-dmsetup/scripts/dmsetup-slx-device
index 8ec27b44..8856a10e 100755
--- a/modules.d/slx-dmsetup/scripts/dmsetup-slx-device
+++ b/modules.d/slx-dmsetup/scripts/dmsetup-slx-device
@@ -323,7 +323,7 @@ declare -g writable_device_used_sz=0
 # first, reserve the space for the rootfs cow snapshot (of either type)...
 read -r name crypt min max ignore <<< "${thin_snapshot:-${snapshot}}"
 
-declare -g scratch_device="$writable_device"
+declare -g scratch_device="/dev/mapper/scratch"
 declare -gi scratch_device_sz=0
 if (( min <= writable_device_sz )); then
 	scratch_device_sz="$max"
@@ -336,6 +336,18 @@ else
 	scratch_device_sz="$writable_device_sz"
 fi
 
+# Create a linear target for the scratch device. This might seem superfluous,
+# but it works around problems when using NVMe as pool data device directly.
+if ! dmsetup_create_noudevsync "${scratch_device##*/}" \
+		"0 $scratch_device_sz linear $writable_device $writable_device_used_sz"; then
+	echo "$0: Failed to create scratch space for the CoW layer."
+	# this should never fail, but if it does, we would likely not be able to use
+	# $writable_device for any dmsetup stuff, so just fallback to ramdisk
+	# until we have a better idea on what to do :)
+	ramdisk_fallback
+fi
+save_partition_info "${scratch_device##*/}" "*" "1" "$scratch_device_sz"
+
 # encrypt the scratch device, if configured
 if [ "$crypt" -ne 0 ] && encrypt_device \
 	"$scratch_device" "${scratch_device##*/}-crypt" "$scratch_device_sz"; then