From: "Lukáš Czerner" <lczerner@redhat.com>
To: Eric Whitney <enwlinux@gmail.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] ext4: don't consume reserved space when allocating partial cluster
Date: Mon, 23 Mar 2015 11:24:37 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.00.1503231117470.1578@localhost.localdomain> (raw)
In-Reply-To: <20150317012009.GA5870@wallace>
On Mon, 16 Mar 2015, Eric Whitney wrote:
> Date: Mon, 16 Mar 2015 21:20:09 -0400
> From: Eric Whitney <enwlinux@gmail.com>
> To: linux-ext4@vger.kernel.org
> Cc: tytso@mit.edu
> Subject: [PATCH] ext4: don't consume reserved space when allocating partial
> cluster
>
> When xfstests' auto group is run on a bigalloc filesystem with a
> 4.0-rc3 kernel, e2fsck failures and kernel warnings occur for some
> tests. e2fsck reports incorrect iblocks values, and the warnings
> indicate that the space reserved by delayed allocation is being
> overdrawn at allocation time.
>
> Some of these errors occur because the reserved space is incorrectly
> decreased by one cluster when ext4_ext_map_blocks satisfies an
> allocation request by using an unused portion of a previously allocated
> cluster. Because a cluster's worth of reserved space was already
> removed when it was first allocated, it should not be removed again.
Hi Eric,
I am not sure I understand. What do you mean by saying that the
space was already removed when it was first allocated ?
>From my point of view the ext4_da_update_reserve_space() call is ok,
because we're going to use blocks from already allocated cluster, so
we do not want to account for quota in this case, because that has
already been done when the cluster was allocated. The rest is just
updating reservations and the dirty clusters counter which needs to
be done in any case. But I might be actually missing something, am I
?
Thanks!
-Lukas
>
> This patch appears to correct the e2fsck failure reported for
> generic/232 and the kernel warnings produced by ext4/001, generic/009,
> and generic/033. Failures and warnings for some other tests remain to
> be addressed.
>
> Signed-off-by: Eric Whitney <enwlinux@gmail.com>
> ---
> fs/ext4/extents.c | 14 +-------------
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index bed4308..554190e 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -4535,19 +4535,7 @@ got_allocated_blocks:
> */
> reserved_clusters = get_reserved_cluster_alloc(inode,
> map->m_lblk, allocated);
> - if (map_from_cluster) {
> - if (reserved_clusters) {
> - /*
> - * We have clusters reserved for this range.
> - * But since we are not doing actual allocation
> - * and are simply using blocks from previously
> - * allocated cluster, we should release the
> - * reservation and not claim quota.
> - */
> - ext4_da_update_reserve_space(inode,
> - reserved_clusters, 0);
> - }
> - } else {
> + if (!map_from_cluster) {
> BUG_ON(allocated_clusters < reserved_clusters);
> if (reserved_clusters < allocated_clusters) {
> struct ext4_inode_info *ei = EXT4_I(inode);
>
next prev parent reply other threads:[~2015-03-23 10:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 1:20 [PATCH] ext4: don't consume reserved space when allocating partial cluster Eric Whitney
2015-03-23 10:24 ` Lukáš Czerner [this message]
2015-03-23 23:15 ` Eric Whitney
2015-03-24 14:31 ` Lukáš Czerner
2015-03-24 21:06 ` Eric Whitney
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=alpine.LFD.2.00.1503231117470.1578@localhost.localdomain \
--to=lczerner@redhat.com \
--cc=enwlinux@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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