Message ID | 20170313075216.5125-7-quwenruo@cn.fujitsu.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Mon, Mar 13, 2017 at 03:52:13PM +0800, Qu Wenruo wrote: > btrfs_qgroup_release/free_data() only returns 0 or minus error > number(ENOMEM is the only possible error). btrfs_qgroup_release_data -> __btrfs_qgroup_release_data will not allocate the ulist anymore, and there are no errors propagated from clear_record_extent_bits (just 0), but there are still some unhandled cases. So here a negative value should be expected anyway. > This is normally good enough, but sometimes we need the accurate byte > number it freed/released. > > Change it to return actually released/freed bytenr number instead of 0 > for success. > And slightly modify related extent_changeset structure, since in btrfs > one none-hole data extent won't be larger than 128M, so "unsigned int" > is large enough for the use case. > - u64 bytes_changed; > + unsigned int bytes_changed; > @@ -2875,6 +2875,7 @@ static int __btrfs_qgroup_release_data(struct inode *inode, u64 start, u64 len, > btrfs_qgroup_free_refroot(BTRFS_I(inode)->root->fs_info, > BTRFS_I(inode)->root->objectid, > changeset.bytes_changed); > + ret = changeset.bytes_changed; This relies on the 128M limit, which will fit to int when assigned. I'm thinking about the signedness, it makes sense to use unsigned for bytes_changed, but we also need the negative error returned. Probably ok. > out: > ulist_release(&changeset.range_changed); > return ret; -- 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 be5477676cc8..89d1bcba3f8c 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4288,7 +4288,7 @@ int btrfs_check_data_free_space(struct inode *inode, u64 start, u64 len) /* Use new btrfs_qgroup_reserve_data to reserve precious data space. */ ret = btrfs_qgroup_reserve_data(inode, start, len); - if (ret) + if (ret < 0) btrfs_free_reserved_data_space_noquota(inode, start, len); return ret; } diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h index 3e4fad4a909d..bdca004dc859 100644 --- a/fs/btrfs/extent_io.h +++ b/fs/btrfs/extent_io.h @@ -201,7 +201,7 @@ struct extent_buffer { */ struct extent_changeset { /* How many bytes are set/cleared in this operation */ - u64 bytes_changed; + unsigned int bytes_changed; /* Changed ranges */ struct ulist range_changed; diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index 9535ea56b6f3..87aeefb34959 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -2875,6 +2875,7 @@ static int __btrfs_qgroup_release_data(struct inode *inode, u64 start, u64 len, btrfs_qgroup_free_refroot(BTRFS_I(inode)->root->fs_info, BTRFS_I(inode)->root->objectid, changeset.bytes_changed); + ret = changeset.bytes_changed; out: ulist_release(&changeset.range_changed); return ret;
btrfs_qgroup_release/free_data() only returns 0 or minus error number(ENOMEM is the only possible error). This is normally good enough, but sometimes we need the accurate byte number it freed/released. Change it to return actually released/freed bytenr number instead of 0 for success. And slightly modify related extent_changeset structure, since in btrfs one none-hole data extent won't be larger than 128M, so "unsigned int" is large enough for the use case. Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> --- fs/btrfs/extent-tree.c | 2 +- fs/btrfs/extent_io.h | 2 +- fs/btrfs/qgroup.c | 1 + 3 files changed, 3 insertions(+), 2 deletions(-)