[Buildd-tools-devel] Bug#477788: why not use the device-mapper?

[Ferenc Wagner]

Hi,

I guess lvm-snapshot was disqualified for wasting too much space,
which is required by the builds but unused by the source chroots.
Basically, one can't create a snapshot bigger that its origin.

Let me share my take on this problem.  It isn't proven yet, so I'd be
especially grateful for comments about why it is utterly silly...

The idea is to augment the lvm-snapshot schema by creating a fresh LV,
appending it to the snapshot and resizing the filesystem on the
resulting block device.  Currently I abuse the chroot description to
carry the size of the extension, lacking anything better.  So:

Set up a 0.5 GB LV by sbuild-createchroot, and configure it like:

[lenny]
description=Debian lenny/i386 autobuilder +2G
type=lvm-snapshot
script-config=enlarger
lvm-snapshot-options=-L 100M
device=/dev/rs22/lenny
priority=3
groups=root,sbuild
root-groups=root,sbuild
run-setup-scripts=true
run-exec-scripts=true
mount-options=-o nouuid

The "enlarger" script is just script-defaults with some glue added:

# Deduce required enlargement from the description
CHROOT_ENLARGE="${CHROOT_DESCRIPTION##*+}"
if [ "$CHROOT_ENLARGE" = "$CHROOT_DESCRIPTION" ]; then
    unset CHROOT_ENLARGE
fi

Yes, a hack, but it isn't the point.  Add setup.d/11growfs:

#!/bin/sh

set -e

if [ -f "$CHROOT_SCRIPT_CONFIG" ]; then
    . "$CHROOT_SCRIPT_CONFIG"
elif [ "$2" = "ok" ]; then
    echo "script-config file '$CHROOT_SCRIPT_CONFIG' does not exist"
    exit 1
fi

if [ "$CHROOT_TYPE" = "lvm-snapshot" ] && [ $1 = "setup-start" ] && [ -n "$CHROOT_ENLARGE" ]; then
    if [ "$AUTH_VERBOSITY" = "verbose" ]; then
        echo "Growing file system"
	xfs_growfs "$CHROOT_MOUNT_LOCATION"
    else
	xfs_growfs "$CHROOT_MOUNT_LOCATION" >/dev/null
    fi
fi

I don't know about a general FS growing utility, but that isn't the
point either.  For now I'm playing with XFS only.

Patch setup.d/05lvm like this:

--- 05lvm.orig	2009-02-24 19:14:03.584443115 +0100
+++ 05lvm	2009-02-24 18:11:47.544023861 +0100
@@ -42,8 +42,29 @@
 		--name "$CHROOT_LVM_SNAPSHOT_NAME" "$CHROOT_DEVICE" > /dev/null
 	fi
 
+	if [ -n "CHROOT_ENLARGE" ]; then
+	    VG=$(lvs --noheadings -o vg_name "$CHROOT_DEVICE" | sed 's/^ *//')
+	    if [ "$AUTH_VERBOSITY" = "verbose" ]; then
+		echo "Creating extension LV of size $CHROOT_ENLARGE"
+		lvcreate $VERBOSE --name "$CHROOT_LVM_SNAPSHOT_NAME"-ext -L "$CHROOT_ENLARGE" $VG
+	    else
+		lvcreate $VERBOSE --name "$CHROOT_LVM_SNAPSHOT_NAME"-ext -L "$CHROOT_ENLARGE" $VG >/dev/null
+	    fi
+	    SD="$CHROOT_LVM_SNAPSHOT_DEVICE"
+	    BSZ=$(blockdev --getsize "$SD")
+	    ESZ=$(blockdev --getsize "$SD"-ext)
+	    [ "$AUTH_VERBOSITY" = "verbose" ] && echo "Merging with the snapshot"
+	    ( echo    0 $BSZ linear "$SD"     0;
+	      echo $BSZ $ESZ linear "$SD"-ext 0) | dmsetup create "$CHROOT_LVM_SNAPSHOT_NAME"-total
+	fi
+
     elif [ $1 = "setup-stop" ]; then
 
+	if [ -n "CHROOT_ENLARGE" ]; then
+	    dmsetup remove "$CHROOT_LVM_SNAPSHOT_NAME"-total || true
+	    lvremove -f "$CHROOT_LVM_SNAPSHOT_DEVICE"-ext || true
+	fi
+
 	if [ -b "$CHROOT_LVM_SNAPSHOT_DEVICE" ]; then
             # The lock needs to be dropped immediately before
             # destroying the device.  There is a small race here, but

And 10mount like this:

--- 10mount.orig	2009-02-24 16:56:32.491075146 +0100
+++ 10mount	2009-02-24 17:50:14.787072524 +0100
@@ -81,7 +81,11 @@
     elif [ "$CHROOT_TYPE" = "loopback" ]; then
 	CHROOT_MOUNT_OPTIONS="$CHROOT_MOUNT_OPTIONS -o loop"
     elif [ "$CHROOT_TYPE" = "lvm-snapshot" ]; then
-	CHROOT_MOUNT_DEVICE="$CHROOT_LVM_SNAPSHOT_DEVICE"
+	if [ -n "$CHROOT_ENLARGE" ]; then
+	    CHROOT_MOUNT_DEVICE="/dev/mapper/$CHROOT_LVM_SNAPSHOT_NAME"-total
+	else
+	    CHROOT_MOUNT_DEVICE="$CHROOT_LVM_SNAPSHOT_DEVICE"
+	fi
     fi
 
     if [ $1 = "setup-start" ] || [ $1 = "setup-recover" ]; then

That's it.  Write +SIZE at the end of the description, and log into
differently sized temporary chroots!  Don't forget to install dmsetup
beforehand, though.

I'd be glad to have something similar in stock schroot.  The above is
mostly a proof of concept, and may well have fatal flaws, but I'm
putting it to work right now.  Opinions welcome!
-- 
Cheers,
Feri.