From: "Fernando Luis Vázquez Cao" <fernando_b1@lab.ntt.co.jp>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Josef Bacik <jbacik@fusionio.com>,
Eric Sandeen <sandeen@redhat.com>,
Dave Chinner <dchinner@redhat.com>,
Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/9 v5] fsfreeze: miscellaneous fixes and cleanups
Date: Fri, 05 Oct 2012 14:24:13 +0900 [thread overview]
Message-ID: <1349414653.7347.2.camel@nexus.lab.ntt.co.jp> (raw)
This patch set is to address long standing issues in the filesytem freeze code
and to fill some functionality gaps in the API. Some minor code rearrangements
are included too.
The following patches are included:
---
[1/9] vfs: add __iterate_supers() helper
[2/9] fsfreeze: add unlocked version of thaw_super
Preparatory patches to fix s_umount lockup of emergency thaw code.
[3/9] fsfreeze: Prevent emergency thaw from looping infinitely
Fix thaw_bdev so that it propagates the error code properly to the caller.
This bug caused emergency thaw to loop infinitely. This is a forward port of
a previous patch by Dave Chinner.
[4/9] fsfreeze: emergency thaw will deadlock on s_umount
Avoid emergency thaw deadlock on s_umount by using unlocked version of
thaw_super() and __iterate_supers()i (introduced in patches 2 and 1
respectively).
[5/9] xfs: switch to using super methods for fsfreeze
[6/9] fsfreeze: move emergency thaw code to fs/super.c
Two cleanups (based on previous patches by David Chinner): convert xfs to using
superblock methods for fsfreeze and move emergency thaw code to where it
belongs.
[7/9] fsfreeze: freeze_super and thaw_bdev don't play well together
These patches address the bdev/sb mismatch and the fact that sb level freezing
does not nest correctly. For all the places that the block device interfaces
are used, we need a superblock anyway so we may as well make freeze/thaw work
only at the superblock level. There is one caveat (pointed out by Christoph in
the discussion linked above) though: we still need to support the "feature"
that we can freeze a block device that does not have a filesystem mounted yet
(this can be used to prevent a filesystem mount during a dm snapshot for
example).
This series moves part of the nesting code to the superblock from the block
device level but retains the freeze_bdev/thaw_bdev API so that we can keep the
"feature" mentioned above for those who may need it, namely dm and external
users (yes, block device level API is exported for external use). All the other
users of the block device API are converted to work at the superblock level.
[8/9] fsfreeze: add vfs ioctl to check freeze state
[9/9] fsfreeze: add block device ioctl to check freeze state
These ioctls can be used to by HA and monitoring software to check the freeze
state of block devices and filesystems.
---
In a follow-up patch set I will tackle a big outstanding problem: we allow
users to umount a frozen filesystem but we have no bdev level fsfreeze API to
thaw it after that. My plan is to add the bdev level API but this requires
some modifications to btrfs and vfs layer that I am still working on. By
the way, the approach of returning EBUSY on umount was discarded because it
would break lazy umount.
Changes since v4:
- Make implementation of iterate_supers_read and iterate_supers_write
symmetric and update locking of emergency thaw code accordingly.
- Add Jan Kara's Reviewed-by to patch 2.
- Add explanation about the change from a block device based emergency thaw
to a superblock based one to patch 4.
- Modify patch 7 so that the new superblock based emergency does not leave
the block device level fsfreeze counter in an inconsistent state.
- Update and comment handling of fsfreeze during mount.
Changes since v3:
- Include right version of the emergency thaw fix (thanks go to Josef for the
heads up).
- Add iterate_supers_(read/write) helpers as suggested by Eric Sandeen.
- Fix typos.
- Add Eric Sandeen's Reviewed-by to patches 2 and 3.
Changes since v2:
- Rebase on top of Jan Kara's patch set which made it upstream.
- Do without the horrible "emergency" parameter as suggested by Jan Kara.
- New approach to fix emergency thaw deadlock on s_umount which does locking
properly.
Changes since v1:
- Do not break unfreezing of block devices without a mounted filesystem.
- Avoid conditional locking in thaw_bdev.
- Update filesystem locking documentation.
next reply other threads:[~2012-10-05 6:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 5:24 Fernando Luis Vázquez Cao [this message]
2012-10-05 5:31 ` [PATCH 1/9] vfs: add __iterate_supers() and helpers around it Fernando Luis Vázquez Cao
2012-10-08 13:48 ` Jan Kara
2012-10-05 5:33 ` [PATCH 2/9] fsfreeze: add unlocked version of thaw_super Fernando Luis Vázquez Cao
2012-10-05 5:34 ` [PATCH 3/9] fsfreeze: Prevent emergency thaw from looping infinitely Fernando Luis Vázquez Cao
2012-10-05 5:35 ` [PATCH 4/9] fsfreeze: emergency thaw will deadlock on s_umount Fernando Luis Vázquez Cao
2012-10-08 13:57 ` Jan Kara
2012-10-09 5:07 ` Fernando Luis Vazquez Cao
2012-10-09 8:20 ` Jan Kara
2012-10-09 9:52 ` Fernando Luis Vazquez Cao
2012-10-05 5:38 ` [PATCH 5/9] xfs: switch to using super methods for fsfreeze Fernando Luis Vázquez Cao
2012-10-05 5:39 ` [PATCH 6/9] fsfreeze: move emergency thaw code to fs/super.c Fernando Luis Vázquez Cao
2012-10-05 5:42 ` [PATCH 7/9] fsfreeze: freeze_super and thaw_bdev don't play well together Fernando Luis Vázquez Cao
2012-10-08 14:17 ` Jan Kara
2012-10-05 5:43 ` [PATCH 8/9] fsfreeze: add vfs ioctl to check freeze state Fernando Luis Vázquez Cao
2012-10-08 15:05 ` Jan Kara
2012-10-09 9:46 ` Fernando Luis Vazquez Cao
2012-10-09 14:55 ` Jan Kara
2012-10-10 2:17 ` Fernando Luis Vazquez Cao
2012-10-11 16:26 ` Jan Kara
2012-10-05 5:44 ` [PATCH 9/9] fsfreeze: add block device " Fernando Luis Vázquez Cao
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=1349414653.7347.2.camel@nexus.lab.ntt.co.jp \
--to=fernando_b1@lab.ntt.co.jp \
--cc=dchinner@redhat.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jbacik@fusionio.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).