[Top] [All Lists]

Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8
From: Stuart Rowan <strr-debian@xxxxxxxxxxxxxxxxxx>
Date: Mon, 30 Mar 2009 14:58:50 +0100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <49D0CCEB.1000404@xxxxxxxxxxx>
References: <49D09F2C.8060406@xxxxxxxxxxxxxxxxxx> <49D0CCEB.1000404@xxxxxxxxxxx>
Reply-to: strr-debian@xxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20090320)
Eric Sandeen wrote, on 30/03/09 14:45:
Stuart Rowan wrote:

We have a backup script running on another machine that ssh's in to the affected server and does the following:
mkdir -p /tmp/foo;
/usr/sbin/xfs_freeze -f /home;
/sbin/lvcreate -s -L 20G -n snap-shot home ;
/usr/sbin/xfs_freeze -u /home;
mount -o nouuid,ro /dev/data/snap-shot /tmp/foo;

It then rsyncs (over ssh) the data to the backup store from /tmp/foo

The above command set hangs at running "/sbin/lvcreate -s -L 20G -n snap-shot home;"

All I/O to /home is of course blocked at this point so for example exim starts queueing up all the mail.

lvcreate now does the fs freeze on its own via the snapshot ioctl, so if
you run freeze manually first, you are stuck behind that first freeze.

Just drop the xfs_freeze's from the above, and all should be well.


Many thanks for your prompt reply and explanation :-)

It's good to know that there's an easy solution ... except we now have to differentiate the commands to run in the backup script based on the version of lvm on the remote system :-$

OOI when implementing the freeze ioctl, what made the developers decide that a freeze can't succeed on an already frozen filesystem ... you'd expect it to just be a no-op really?


<Prev in Thread] Current Thread [Next in Thread>