Re: xfs_freeze -f misbehaving under lenny / xfsprogs 2.9.8

[Eric Sandeen <sandeen@sandeen.net>]

Stuart Rowan wrote:
> Eric Sandeen wrote, on 30/03/09 14:45:
>> Stuart Rowan wrote:
>>> Hi,
>>>
>>> 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.
>>
>> -Eric
> Eric,
> 
> 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...

-Eric

> Cheers,
> Stu.
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs