Skip to content

RFC fsfreeze: fix sb vs bdev freeze/thaw b0rkage

Dave Chinner linux-fsdevel lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest5 patches 12 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/5fsfreeze: Prevent emergency thaw from looping infinitelyfs/block_dev.c+5 -82 replies
2/5fsfreeze: emergency thaw will deadlock on s_umountfs/block_dev.c fs/buffer.c fs/super.c +1 more+81 -144 replies
3/5fsfreeze: freeze_super and thaw_bdev don't play well togetherfs/block_dev.c fs/gfs2/ops_fstype.c fs/super.c +1 more+56 -1003 replies
4/5fsfreeze: switch to using super methods everywheredrivers/md/dm.c fs/block_dev.c fs/buffer.c +3 more+13 -861 reply
5/5fsfreeze: move emergency thaw code to fs/super.cfs/buffer.c fs/super.c include/linux/fs.h+33 -361 reply

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [RFC, PATCH 0/5] fsfreeze: fix sb vs bdev freeze/thaw b0rkage

The following series is for to address bugs in the emergency thawing code, as well as mismatcheѕ with freezing at the block layer and the superblock that break the freeze/thaw nesting order.

The first two patches fix the emergency thaw infinite loop reported by Jeff Merkey and the deadlock on sb->s_umount that the infinite loop hid. These may be stable kernel candidates.

The remainder of the patches address the bdev/sb mismatch and the fact that sb level freezing does not nest correctly. For all the places that the bdev interfaces are used, we need a superblock anyway so we may as well make freeze/thaw work only at the sb level. As such, this series moves all the nesting code to the sb from the bdev level and removes the freeze_bdev/thaw_bdev interfaces completely. It also converts the emergency thaw to work at the superblock level such that it will now thaw manually frozen filesystems.

A *big* outstanding problem still exists - freezing takes an active reference to the superblock, so unmounting an frozen filesystem has some nasty and unexpected side effects. The existing code results in an unmountable block device:

# mount /dev/vda /mnt/test
# xfs_freeze -f /mnt/test
# umount /mnt/test
# grep test /proc/mounts
# mkfs.xfs -f -l size=128m /dev/vda
mkfs.xfs: /dev/vda contains a mounted filesystem
Usage: mkfs.xfs
....
# mount /dev/vda /mnt/test
mount: /dev/vda already mounted or /mnt/test busy
#

At this point I can't get access to /dev/vda and needs a reboot to get it and /mnt/test back.

This patch series results in the block device being mountable, but remains frozen across unmount/mount:

# mount /dev/vda /mnt/test
# xfs_freeze -f /mnt/test
# umount /mnt/test
# grep test /proc/mounts
# mkfs.xfs -f -l size=128m /dev/vda
mkfs.xfs: /dev/vda contains a mounted filesystem
Usage: mkfs.xfs
....
# mount /dev/vda /mnt/test
# touch /mnt/test/foo &
[1] 2647
#
# xfs_freeze -u /mnt/test
[1]+  Done                    sudo touch /mnt/test/foo
# umount /mnt/test
# mkfs.xfs -f -l size=128m /dev/vda
meta-data=/dev/vda               isize=256    agcount=4, agsize=262144 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=1048576, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
#

This behaviour is only marginally better than the existing behaviour (at least you can release the references). However, I don't really like either option - we used to disallow umount on a frozen filesystems to avoid this problem.

So What is really supposed to happen when we unmount a frozen superblock? Should unmount return EBUSY? Should it be automatically thawed so it doesn't affect block device behaviour after unmount? Something else?

Cheers,

Dave.