From: Chris Mason <chris.mason@fusionio.com>
To: David Sterba <dsterba@suse.cz>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Cc: "alex.btrfs@zadarastorage.com" <alex.btrfs@zadarastorage.com>,
David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH v3] btrfs: clean snapshots one by one
Date: Mon, 6 May 2013 20:41:06 -0400 [thread overview]
Message-ID: <20130507004106.5844.39433@localhost.localdomain> (raw)
In-Reply-To: <1363101208-30184-1-git-send-email-dsterba@suse.cz>
Quoting David Sterba (2013-03-12 11:13:28)
> Each time pick one dead root from the list and let the caller know if
> it's needed to continue. This should improve responsiveness during
> umount and balance which at some point waits for cleaning all currently
> queued dead roots.
>
> A new dead root is added to the end of the list, so the snapshots
> disappear in the order of deletion.
>
> The snapshot cleaning work is now done only from the cleaner thread and the
> others wake it if needed.
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index 988b860..4de2351 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -1690,15 +1690,19 @@ static int cleaner_kthread(void *arg)
> struct btrfs_root *root = arg;
>
> do {
> + int again = 0;
> +
> if (!(root->fs_info->sb->s_flags & MS_RDONLY) &&
> + down_read_trylock(&root->fs_info->sb->s_umount) &&
> mutex_trylock(&root->fs_info->cleaner_mutex)) {
> btrfs_run_delayed_iputs(root);
> - btrfs_clean_old_snapshots(root);
> + again = btrfs_clean_one_deleted_snapshot(root);
> mutex_unlock(&root->fs_info->cleaner_mutex);
> btrfs_run_defrag_inodes(root->fs_info);
> + up_read(&root->fs_info->sb->s_umount);
Can we use just the cleaner mutex for this? We're deadlocking during
068 with autodefrag on because the cleaner is holding s_umount while
autodefrag is trying to bump the writer count.
If unmount takes the cleaner mutex once it should wait long enough for
the cleaner to stop.
-chris
next prev parent reply other threads:[~2013-05-07 0:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-12 15:13 [PATCH v3] btrfs: clean snapshots one by one David Sterba
2013-03-16 19:34 ` Alex Lyakas
2013-05-07 0:41 ` Chris Mason [this message]
2013-05-07 11:54 ` David Sterba
2013-05-10 13:04 ` Chris Mason
2013-05-14 6:32 ` Miao Xie
2013-07-04 15:29 ` Alex Lyakas
2013-07-04 17:03 ` David Sterba
2013-07-04 19:52 ` Alex Lyakas
2013-07-05 2:21 ` Josef Bacik
2013-07-14 16:20 ` Alex Lyakas
2013-07-15 16:41 ` 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=20130507004106.5844.39433@localhost.localdomain \
--to=chris.mason@fusionio.com \
--cc=alex.btrfs@zadarastorage.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/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.