On Tue, Jun 08, 2010 at 10:58:52PM +1000, Dave Chinner wrote: > On Tue, Jun 08, 2010 at 12:26:52PM +1000, Dave Chinner wrote: > > On Mon, Jun 07, 2010 at 10:07:41PM -0400, Josef Bacik wrote: > > > Well damnit. I guess what we need to do is get rid of the freeze_bdev/thaw_bdev > > > interface altogether, and move the count stuff down to the super. Anybody who > > > calls freeze_bdev/thaw_bdev knows the sb anyway, so if we get rid of > > > bd_fsfreeze_count and move it to sb->s_fsfreeze_count and do the same with > > > bd_fsfreeze_mutex then we could solve this altogether and simplify the > > > interface. It grows the sb struct, but hey it shrinks the bdev struct :). How > > > horrible of an idea is that? Thanks, > > > > Kind of what I was thinking of. I wasn't sure about what btrfs > > required, but you've cleared that up. I'll put a patch together and > > see how it looks. > > Not too bad: > > 8 files changed, 137 insertions(+), 190 deletions(-) > > It really needs to be split up into multiple commits and the test > case needs to exercise dmsetup suspend/resume as well, but I think > this works well enough for comments at this point. I've only tested > it on XFS so far. > I like it. Everything seems in order, course now I realize that dm trying to freeze a bdev with btrfs on it will not work, but thats a seperate, horrible situation that can wait till later :). Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
