Stuart Rowan wrote:
> 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 :-$
can't be *that* bad ... ;)
> 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?
To complicate matters more, on newer upstream kernels w/ the freeze
ioctl exposed for all filesystems, nested freezes are in fact supported.
I'm not sure why sequential freezes were serialized initially, TBH...