teh fear

Having started to play with xen on linux, I have begun to use loop filesystems (a filesystem embedded in a file) rather a lot.

Xen virtual servers are, fairly often, run from within a loop filesystem and generally start with a fairly small file (1GB is big for a normal file, but not when it is pretending to be an entire filesystem!)

Here’s a nice simple shortcut for increasing the size of a loop fs (if the filesystem is ext2/ext3) …

1. Stop the virtual server that is using the loop fs (if appropriate)
2. Add some extra space to your loopfs file, in much the same way as it was originally created (possibly)
   dd if=/dev/zero bs=1024k count=1024 >> my_loop_image_file
   The above adds 1GB to the end of a file called my_loop_image_file (make sure to use the append output redirector ‘>>’ not a single ‘>’, otherwise you’ll have an empty 1GB file!)
3. Force a check on the filesystem
   e2fsck -f my_loop_image_file
4. Resize the filesystem within the loopfs file
   resize2fs my_loop_image_file
5. Restart the virtual server (again if appropriate)

One could also use resize2fs to reduce the size of the filesystem…

You will have to tell resize2fs the new size of your filesystem (a simple extra parameter after the device/file, by default in blocks but can be suffixed by one of the following the unit designators: ’s’, ‘K’, ‘M’, or ‘G’, for 512 byte sectors, kilobytes, megabytes, or gigabytes, respectively)
resize2fs my_loop_image_file 1024M
The above would resize the filesystem to be 1GB in size
NOTE: The actual size required in the loop file may be more than this – 1GB of storage in a filesystem takes more than 1GB on the disk, some space is required for management info.

You would then have to find a way to reduce the size of your loopfs file…
dd if=my_loop_image_file of=my_smaller_image_file bs=1024k count=1024
Would copy the first 1GB from the existing loop file to a new file – remember some extra space may be required here, don’t delete the original file until you are sure you have achieved what you wanted.

Probably safe to resize your filesystem smaller than necessary, then shrink the loop file to the desired size, then resize the filesystem again to fill as much of the loop file as possible.

alternatively…

You could just create a new loop image file of the required size
dd if=/dev/zero of=my_new_image_file bs=1024k count=2048
mke2fs -j my_new_image_file
Then mount both the old and new partitions
mkdir /mnt/old
mkdir /mnt/new
mount my_old_image_file /mnt/old
mount my_new_image_file /mnt/new
Then simply copy the files from one partiton to another
cd /mnt/old
cp -auxv ./ /mnt/new/
a – keep the same attributes
u – if the file already exists at the destination, only copy if the source is newer (useful if you need to restart)
x – stay on one filesystem (otherwise you’ll copy /proc/… and /mnt/tmp/…)
v – be verbose (I like to see what is going on).

once finished, unmount both devices
umount /mnt/old
umount /mnt/new

But… my loop image has partitions

Well then you’ll need something that can treat a loop image as if it was an actual disk…
If you have a xen virtual machine, you could boot into that with both old and new loop files connected.

If the loop file you are resizing is your xen vm, you could boot into it (with the old and new loop image attached) in single user mode in order to do the copy (I have had to employ this method several times on physical hardware). Being in single user mode ensures that you are the only one modifying files.

To boot a xen linux vm in single user mode add a line to the domain config file
extra = "1"
or append to what is there – this
extra = "ro selinux=0 1"
or, if you are using pygrub, on the boot screen press ‘e’ to edit the entry, then press ‘e’ on the kernel line and add ‘ 1′ to then end of the line, press return then press ‘b’ to boot.
then follow the mount/ copy route above.