From: Dave Chinner <david@fromorbit.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, viro@ZenIV.linux.org.uk,
josef@redhat.com, jeffmerkey@gmail.com
Subject: [RFC, PATCH 0/5] fsfreeze: fix sb vs bdev freeze/thaw b0rkage
Date: Thu, 10 Jun 2010 17:19:49 +1000 [thread overview]
Message-ID: <1276154395-24766-1-git-send-email-david@fromorbit.com> (raw)
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.
next reply other threads:[~2010-06-10 7:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-10 7:19 Dave Chinner [this message]
2010-06-10 7:19 ` [PATCH 1/5] fsfreeze: Prevent emergency thaw from looping infinitely Dave Chinner
2010-06-14 15:18 ` Christoph Hellwig
2010-06-14 23:19 ` Dave Chinner
2010-06-10 7:19 ` [PATCH 2/5] fsfreeze: emergency thaw will deadlock on s_umount Dave Chinner
2010-06-14 15:20 ` Christoph Hellwig
2010-06-14 23:21 ` Dave Chinner
2010-06-21 1:57 ` Dave Chinner
2010-06-21 7:47 ` Christoph Hellwig
2010-06-10 7:19 ` [PATCH 3/5] fsfreeze: freeze_super and thaw_bdev don't play well together Dave Chinner
2010-06-14 15:22 ` Christoph Hellwig
2010-06-15 0:01 ` Dave Chinner
2010-06-15 6:24 ` Christoph Hellwig
2010-06-10 7:19 ` [PATCH 4/5] fsfreeze: switch to using super methods everywhere Dave Chinner
2010-06-14 15:23 ` Christoph Hellwig
2010-06-10 7:19 ` [PATCH 5/5] fsfreeze: move emergency thaw code to fs/super.c Dave Chinner
2010-06-14 15:25 ` Christoph Hellwig
2010-06-10 12:45 ` [RFC, PATCH 0/5] fsfreeze: fix sb vs bdev freeze/thaw b0rkage Josef Bacik
2010-06-10 12:45 ` Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1276154395-24766-1-git-send-email-david@fromorbit.com \
--to=david@fromorbit.com \
--cc=jeffmerkey@gmail.com \
--cc=josef@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.