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@vger.kernel.org/msg60418.html > > I'm also getting a notifier that wang's email does not exist anymore > (wangxg.f...@cn.fujitsu.com). > > 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 majord...@vger.kernel.org >>> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
