I sent mail to David asking about these unmerged patchset, but no reply yet.
And to my surprise, the patch even disappeared from david's for-next branch.
Not sure what's wrong with all these unmerged patches.
Thanks,
Qu
At 02/25/2017 04:23 PM, Stefan Priebe - Profihost AG wrote:
Dear Qu,
any news on your branch? I still don't see it merged anywhere.
Greets,
Stefan
Am 04.01.2017 um 17:13 schrieb Stefan Priebe - Profihost AG:
Hi Qu,
Am 01.01.2017 um 10:32 schrieb Qu Wenruo:
Hi Stefan,
I'm trying to push it to for-next (will be v4.11), but no response yet.
It would be quite nice for you to test the following git pull and give
some feedback, so that we can merge it faster.
https://mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg60418.html
I'm also getting a notifier that wang's email does not exist anymore
(wangxg.fnst@xxxxxxxxxxxxxx).
I would like to test that branch will need some time todo so. Last time
i tried 4.10-rc1 i had the same problems like this guy:
https://www.marc.info/?l=linux-btrfs&m=148338312525137&w=2
Stefan
Thanks,
Qu
On 12/31/2016 03:31 PM, Stefan Priebe - Profihost AG wrote:
Any news on this series? I can't see it in 4.9 nor in 4.10-rc
Stefan
Am 11.11.2016 um 09:39 schrieb Wang Xiaoguang:
When having compression enabled, Stefan Priebe ofen got enospc errors
though fs still has much free space. Qu Wenruo also has submitted a
fstests test case which can reproduce this bug steadily, please see
url: https://patchwork.kernel.org/patch/9420527
First patch[1/3] "btrfs: improve inode's outstanding_extents
computation" is to
fix outstanding_extents and reserved_extents account issues. This
issue was revealed
by modifying BTRFS_MAX_EXTENT_SIZE(128MB) to 64KB, When modifying
BTRFS_MAX_EXTENT_SIZE(128MB) to 64KB, fsstress test often gets these
warnings from
btrfs_destroy_inode():
WARN_ON(BTRFS_I(inode)->outstanding_extents);
WARN_ON(BTRFS_I(inode)->reserved_extents);
Please see this patch's commit message for detailed info, and this
patch is
necessary to patch2 and patch3.
For false enospc, the root reasson is that for compression, its max
extent size will
be 128k, not 128MB. If we still use 128MB as max extent size to
reserve metadata for
compression, obviously it's not appropriate. In patch "btrfs:
Introduce COMPRESS
reserve type to fix false enospc for compression" commit message,
we explain why false enospc error occurs, please see it for detailed
info.
To fix this issue, we introduce a new enum type:
enum btrfs_metadata_reserve_type {
BTRFS_RESERVE_NORMAL,
BTRFS_RESERVE_COMPRESS,
};
For btrfs_delalloc_[reserve|release]_metadata() and
btrfs_delalloc_[reserve|release]_space(), we introce a new
btrfs_metadata_reserve_type
argument, then if a path needs to go compression, we pass
BTRFS_RESERVE_COMPRESS,
otherwise pass BTRFS_RESERVE_NORMAL.
With these patchs, Stefan no longer saw such false enospc errors, and
Qu Wenruo's
fstests test case will also pass. I have also run whole fstests
multiple times,
no regression occurs, thanks.
Wang Xiaoguang (3):
btrfs: improve inode's outstanding_extents computation
btrfs: introduce type based delalloc metadata reserve
btrfs: Introduce COMPRESS reserve type to fix false enospc for
compression
fs/btrfs/ctree.h | 36 +++++--
fs/btrfs/extent-tree.c | 52 ++++++---
fs/btrfs/extent_io.c | 61 ++++++++++-
fs/btrfs/extent_io.h | 5 +
fs/btrfs/file.c | 25 +++--
fs/btrfs/free-space-cache.c | 6 +-
fs/btrfs/inode-map.c | 6 +-
fs/btrfs/inode.c | 246
++++++++++++++++++++++++++++++++++---------
fs/btrfs/ioctl.c | 16 +--
fs/btrfs/relocation.c | 14 ++-
fs/btrfs/tests/inode-tests.c | 15 +--
11 files changed, 381 insertions(+), 101 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
