Hi:
What Would Xfs Snapshot Do?
Xfs_freeze
SYSïLinux localhost.localdomain 3.10.0-54.0.1.el7.x86_64 #1 SMP Tue Nov 26
16:51:22 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
-----éäåä-----
åää: Dave Chinner [mailto:david@xxxxxxxxxxxxx]
åéæé: 2014å6æ19æ 13:42
æää: éæä
æé: xfs@xxxxxxxxxxx
äé: Re: xfs_freeze
On Thu, Jun 19, 2014 at 05:09:04AM +0000, éæä wrote:
> Hi:
>
> [root@localhost /]# mount /dev/lvm_vg/lvm_lv /nas/ [root@localhost /]#
> xfs_freeze -f /nas/ [root@localhost /]# lvcreate -s -L 40M -n cwd
> /dev/lvm_vg/lvm_lv
> Rounding up size to full physical extent 48.00 MiB
> device-mapper: suspend ioctl on failed: Device or resource busy
> Unable to suspend lvm_vg-lvm_lv (253:0)
> Failed to suspend origin lvm_lv
> libdevmapper exiting with 2 device(s) still suspended.
>
>
>
>
> Why?
commit 18e9e5104fcd9a973ffe3eed3816c87f2a1b6cd2
Author: Josef Bacik <josef@xxxxxxxxxx>
Date: Tue Mar 23 10:34:56 2010 -0400
Introduce freeze_super and thaw_super for the fsfreeze ioctl
Currently the way we do freezing is by passing sb>s_bdev to freeze_bdev and
the
letting it do all the work. But freezing is more of an fs thing, and
doesn't
really have much to do with the bdev at all, all the work gets done with the
super. In btrfs we do not populate s_bdev, since we can have multiple
bdev's
for one fs and setting s_bdev makes removing devices from a pool kind of
tricky
This means that freezing a btrfs filesystem fails, which causes us to
corrupt
with things like tux-on-ice which use the fsfreeze mechanism. So instead of
populating sb->s_bdev with a random bdev in our pool, I've broken the
actual fs
freezing stuff into freeze_super and thaw_super. These just take the
super_block that we're freezing and does the appropriate work. It's
basically
just copy and pasted from freeze_bdev. I've then converted freeze_bdev
over to
use the new super helpers. I've tested this with ext4 and btrfs and
verified
everything continues to work the same as before.
The only new gotcha is multiple calls to the fsfreeze ioctl will return
EBUSY i
the fs is already frozen. I thought this was a better solution than adding
a
freeze counter to the super_block, but if everybody hates this idea I'm
open to
suggestions. Thanks,
Signed-off-by: Josef Bacik <josef@xxxxxxxxxx>
Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
IOWs, if you freeze the superblock via xfs_freeze or fsfreeze, you cannot nest
freeze requests - you'll get EBUSY on teh second attempt to freeze the
superblock.
lvcreate must be doing a freeze from the block device, so it's failing with
EBUSY because the superblock on the block device is already frozen...
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|