| Message ID | 1458926760-17563-6-git-send-email-jbacik@fb.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
Hi Josef, Would you please move this patch to the first of the patchset? It's making bisect quite hard, as it will always stop at this patch, hard to check if it's a regression or existing bug. Thanks, Qu At 03/26/2016 01:25 AM, Josef Bacik wrote: > These were hidden behind enospc_debug, which isn't helpful as they indicate > actual bugs, unlike the rest of the enospc_debug stuff which is really debug > information. Thanks, > > Signed-off-by: Josef Bacik <jbacik@fb.com> > --- > fs/btrfs/extent-tree.c | 14 ++++++++------ > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index 157a0b6..90ac821 100644 > --- a/fs/btrfs/extent-tree.c > +++ b/fs/btrfs/extent-tree.c > @@ -9633,13 +9633,15 @@ int btrfs_free_block_groups(struct btrfs_fs_info *info) > space_info = list_entry(info->space_info.next, > struct btrfs_space_info, > list); > - if (btrfs_test_opt(info->tree_root, ENOSPC_DEBUG)) { > - if (WARN_ON(space_info->bytes_pinned > 0 || > + > + /* > + * Do not hide this behind enospc_debug, this is actually > + * important and indicates a real bug if this happens. > + */ > + if (WARN_ON(space_info->bytes_pinned > 0 || > space_info->bytes_reserved > 0 || > - space_info->bytes_may_use > 0)) { > - dump_space_info(space_info, 0, 0); > - } > - } > + space_info->bytes_may_use > 0)) > + dump_space_info(space_info, 0, 0); > list_del(&space_info->list); > for (i = 0; i < BTRFS_NR_RAID_TYPES; i++) { > struct kobject *kobj; > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/27/2016 12:47 AM, Qu Wenruo wrote: > Hi Josef, > > Would you please move this patch to the first of the patchset? > > It's making bisect quite hard, as it will always stop at this patch, > hard to check if it's a regression or existing bug. That's a good idea. Which workload are you having trouble with? -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
At 06/27/2016 09:03 PM, Chris Mason wrote: > > > On 06/27/2016 12:47 AM, Qu Wenruo wrote: >> Hi Josef, >> >> Would you please move this patch to the first of the patchset? >> >> It's making bisect quite hard, as it will always stop at this patch, >> hard to check if it's a regression or existing bug. > > That's a good idea. Which workload are you having trouble with? > > -chris > > Qgroup test which hits EDQUOTA. After hitting EDQUOTA, unmount will always trigger a kernel warning, for DATA space whose byte_may_use is not zero. The problem is long existing, seems to be buffered write doesn't clean up its delalloc reserved DATA space. Thanks, Qu -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 157a0b6..90ac821 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -9633,13 +9633,15 @@ int btrfs_free_block_groups(struct btrfs_fs_info *info) space_info = list_entry(info->space_info.next, struct btrfs_space_info, list); - if (btrfs_test_opt(info->tree_root, ENOSPC_DEBUG)) { - if (WARN_ON(space_info->bytes_pinned > 0 || + + /* + * Do not hide this behind enospc_debug, this is actually + * important and indicates a real bug if this happens. + */ + if (WARN_ON(space_info->bytes_pinned > 0 || space_info->bytes_reserved > 0 || - space_info->bytes_may_use > 0)) { - dump_space_info(space_info, 0, 0); - } - } + space_info->bytes_may_use > 0)) + dump_space_info(space_info, 0, 0); list_del(&space_info->list); for (i = 0; i < BTRFS_NR_RAID_TYPES; i++) { struct kobject *kobj;
These were hidden behind enospc_debug, which isn't helpful as they indicate actual bugs, unlike the rest of the enospc_debug stuff which is really debug information. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com> --- fs/btrfs/extent-tree.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)