From: Josef Bacik <jbacik@fb.com>
To: Miao Xie <miaox@cn.fujitsu.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH V2 10/10] Btrfs: reclaim the reserved metadata space at background
Date: Mon, 10 Mar 2014 09:35:13 -0400 [thread overview]
Message-ID: <531DBF91.60701@fb.com> (raw)
In-Reply-To: <1394085304-32589-10-git-send-email-miaox@cn.fujitsu.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/06/2014 12:55 AM, Miao Xie wrote:
> Before applying this patch, the task had to reclaim the metadata
> space by itself if the metadata space was not enough. And When the
> task started the space reclamation, all the other tasks which
> wanted to reserve the metadata space were blocked. At some cases,
> they would be blocked for a long time, it made the performance
> fluctuate wildly.
>
> So we introduce the background metadata space reclamation, when the
> space is about to be exhausted, we insert a reclaim work into the
> workqueue, the worker of the workqueue helps us to reclaim the
> reserved space at the background. By this way, the tasks needn't
> reclaim the space by themselves at most cases, and even if the
> tasks have to reclaim the space or are blocked for the space
> reclamation, they will get enough space more quickly.
>
> We needn't worry about the early enospc problem because all the
> reclaim work is serialized by the lock.
>
> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
This causes generic/015 to fail with early enospc, I'm kicking this
patch out, I'll take the rest. Thanks,
Josef
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTHb+NAAoJEANb+wAKly3BCcUP/jGmW85hiurfTF7eom+wzDcr
nxqvdTB/F21UJU1RRrb92CdYRYb9d4hHKhXE5OK+qamE+K55GEtgCUWCLQgDfJJL
Wx0aUD/pTqv3J5S5zM43UBJkn2ZR99Q7hJzm9PPMSMn7hBgK87QUEme8HerCPUgY
0VS4OcqUGhg88qO8GjdEFLnHawhjMDw9iGPUi+tMdCEmr9aQQo8ntiahdVKyTHej
vSRQRs0igvAt73OWHXiP6vc4LOQdu1vKCFdbxhgg+duKjNOHfUoaiiaUiGhWIA9l
BcTWd62bEJNOaXd6k06GzhpCWzMM6faTLfjI6XADUFY0VZ79akzk2KAO6YdaLz8w
3IAKN1chTpr7q7oPuRDgDQuwwdeLPImN29CKlAF3jlSRJEblM8CKoXYD1fyqVwDy
c1mA6mMUJnEnXrkJ/Pb5zuNIZMAlU+v3d6CCjYKHMACORvJeZVlg9gLLMATaAJIA
xLjFlzbgSbp/OUNuBuS4YGIaa51aAyODd2h1T3E+T5JYbVkA39N3Ni9HODE8AuSE
E6U/06FK47L0e5uGFrM3tMTL0XBF62C1iml4NsjOWgiERz8lFDdFVArgXamCVacM
1+VdeLLS88RHFEuwlMBy/ZQBdnvWCVsNVjYukuxntmWbSWrsLUFUSzExWnp+7TAO
xkEd2yMw75yasTVGKSXU
=Q/fM
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-03-10 13:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 5:54 [PATCH V2 01/10] Btrfs: fix early enospc due to the race of the two ordered extent wait Miao Xie
2014-03-06 5:54 ` [PATCH V2 02/10] Btrfs: wake up the tasks that wait for the io earlier Miao Xie
2014-03-27 16:57 ` David Sterba
2014-03-06 5:54 ` [PATCH V2 03/10] Btrfs: just do dirty page flush for the inode with compression before direct IO Miao Xie
2014-03-06 5:54 ` [PATCH V2 04/10] Btrfs: remove the unnecessary flush when preparing the pages Miao Xie
2014-03-06 5:54 ` [PATCH V2 05/10] Btrfs: remove unnecessary lock in may_commit_transaction() Miao Xie
2014-03-06 5:55 ` [PATCH V2 06/10] Btrfs: reclaim delalloc metadata more aggressively Miao Xie
2014-03-06 5:55 ` [PATCH V2 07/10] Btrfs: don't flush all delalloc inodes when we doesn't get s_umount lock Miao Xie
2014-03-06 5:55 ` [PATCH V2 08/10] Btrfs: split the global ordered extents mutex Miao Xie
2014-03-06 5:55 ` [PATCH V2 09/10] Btrfs: fix possible empty list access when flushing the delalloc inodes Miao Xie
2014-03-06 5:55 ` [PATCH V2 10/10] Btrfs: reclaim the reserved metadata space at background Miao Xie
2014-03-10 13:35 ` Josef Bacik [this message]
2014-05-08 2:06 ` Miao Xie
2014-05-08 2:21 ` [PATCH V3] " Miao Xie
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=531DBF91.60701@fb.com \
--to=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
/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.