diff options
author | 2020-01-02 16:26:46 -0500 | |
---|---|---|
committer | 2020-01-20 16:41:01 +0100 | |
commit | 81b29a3bf7cce4373526ff91a7a89aa6505597f7 (patch) | |
tree | 2fe26501894495a31b10a55b90b11d1e8718d808 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | btrfs: ensure removal of discardable_* in free_bitmap() (diff) | |
download | wireguard-linux-81b29a3bf7cce4373526ff91a7a89aa6505597f7.tar.xz wireguard-linux-81b29a3bf7cce4373526ff91a7a89aa6505597f7.zip |
btrfs: add correction to handle -1 edge case in async discard
From Dave's testing described below, it's possible to drive a file
system to have bogus values of discardable_extents and _bytes. As
btrfs_discard_calc_delay() is the only user of discardable_extents, we
can correct here for any negative discardable_extents/discardable_bytes.
The problem is not reliably reproducible. The workload that created it
was based on linux git tree, switching between release tags, then
everytihng deleted followed by a full rebalance. At this state the
values of discardable_bytes was 16K and discardable_extents was -1,
expected values 0 and 0.
Repeating the workload again did not correct the bogus values so the
offset seems to be stable once it happens.
Reported-by: David Sterba <dsterba@suse.com>
Signed-off-by: Dennis Zhou <dennis@kernel.org>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions