From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@kernel.org
Subject: [Bug 151491] free space lossage on busy system with bigalloc enabled and 128KB cluster
Date: Thu, 30 Nov 2017 16:08:41 +0000 [thread overview]
Message-ID: <bug-151491-13602-6X9NJMdKhv@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-151491-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=151491
--- Comment #14 from Eric Whitney (enwlinux@gmail.com) ---
I've been able to identify the unknown contributor to the delalloc accounting
error as discussed previously (in comment 10).
When ext4 is writing back a previously delalloc'ed extent that contains just a
portion of a cluster, and then delallocs an extent that contains another
disjoint portion of that same cluster, the count of delalloc'ed clusters
(i_reserved_data_blocks) is incorrectly incremented. The cluster has been
physically allocated during writeback, but the subsequent delalloc write does
not discover that allocation. This is because the code in ext4_da_map_blocks()
checks for a previously physically allocated block at the point of allocation
rather than a previously physically allocated cluster spanning the point of
allocation.
The effect is to bump the delalloc'ed cluster count for clusters that will
never be allocated (since they've already been allocated), and the overcount
will therefore never be reduced.
It's more likely this problem would occur when writing files sequentially if
the test system was under memory pressure, resulting in writeback activity in
parallel with delalloc writes. The magnitude of the overcount is also likely
to be larger in this situation. This correlates well with the observation that
the reproducer for the accounting errors is more likely to reproduce the
problem on a test system with little free memory.
I've been testing a prototype patch that appears to fix this problem. However,
I've also identified at least two other unrelated delalloc accounting problems
for bigalloc file systems whose effects are masked by the other contributor to
overcounting in ext4_ext_map_blocks(). Fixing it results in failures caused by
these other problems when running xfstests-bld on bigalloc. So, there's a lot
of work yet to be done before it's time to post patches.
--
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2017-11-30 16:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-04 19:47 [Bug 151491] New: free space lossage on busy system with bigalloc enabled and 128KB cluster bugzilla-daemon
2016-08-06 12:54 ` [Bug 151491] " bugzilla-daemon
2016-08-08 20:30 ` bugzilla-daemon
2016-08-09 18:28 ` bugzilla-daemon
2017-11-11 11:04 ` bugzilla-daemon
2017-11-11 19:20 ` bugzilla-daemon
2017-11-13 16:27 ` bugzilla-daemon
2017-11-13 17:27 ` bugzilla-daemon
2017-11-13 17:30 ` bugzilla-daemon
2017-11-13 17:39 ` bugzilla-daemon
2017-11-16 23:54 ` bugzilla-daemon
2017-11-17 16:00 ` bugzilla-daemon
2017-11-20 15:50 ` bugzilla-daemon
2017-11-20 17:59 ` bugzilla-daemon
2017-11-30 16:08 ` bugzilla-daemon [this message]
2017-12-02 11:35 ` bugzilla-daemon
2018-01-27 9:25 ` bugzilla-daemon
2018-01-27 14:20 ` bugzilla-daemon
2018-01-27 19:28 ` bugzilla-daemon
2018-12-03 17:10 ` bugzilla-daemon
2018-12-11 16:44 ` bugzilla-daemon
2018-12-11 18:57 ` bugzilla-daemon
2018-12-13 16:12 ` bugzilla-daemon
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=bug-151491-13602-6X9NJMdKhv@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-ext4@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox