| Message ID | 20170512033046.31981-4-quwenruo@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, May 12, 2017 at 11:30:43AM +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/free_data() only returns 0 or a negative 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" ^^^^^^^^^ NO_HOLES or no-hole > 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(-) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index e390451c72e6..4f62696131a6 100644 > --- a/fs/btrfs/extent-tree.c > +++ b/fs/btrfs/extent-tree.c > @@ -4298,7 +4298,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 1eafa2f0ede3..cc1b08fa9fe7 100644 > --- a/fs/btrfs/extent_io.h > +++ b/fs/btrfs/extent_io.h > @@ -205,7 +205,7 @@ struct extent_buffer { > */ > struct extent_changeset { > /* How many bytes are set/cleared in this operation */ > - u64 bytes_changed; > + unsigned int bytes_changed; The alignment constraints will insert 4 bytes anyway, so we don't save any space, but unsigned int is fine here, as we're not going to utilize u64. > /* Changed ranges */ > struct ulist range_changed; > diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c > index 9f01c25469f7..ad2e99491395 100644 > --- a/fs/btrfs/qgroup.c > +++ b/fs/btrfs/qgroup.c > @@ -2886,6 +2886,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; > -- > 2.12.2 > > > > -- > 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 -- 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 05/16/2017 10:23 PM, David Sterba wrote: > On Fri, May 12, 2017 at 11:30:43AM +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/free_data() only returns 0 or a negative 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" > ^^^^^^^^^ > NO_HOLES or no-hole > >> 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(-) >> >> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c >> index e390451c72e6..4f62696131a6 100644 >> --- a/fs/btrfs/extent-tree.c >> +++ b/fs/btrfs/extent-tree.c >> @@ -4298,7 +4298,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 1eafa2f0ede3..cc1b08fa9fe7 100644 >> --- a/fs/btrfs/extent_io.h >> +++ b/fs/btrfs/extent_io.h >> @@ -205,7 +205,7 @@ struct extent_buffer { >> */ >> struct extent_changeset { >> /* How many bytes are set/cleared in this operation */ >> - u64 bytes_changed; >> + unsigned int bytes_changed; > > The alignment constraints will insert 4 bytes anyway, so we don't save > any space, but unsigned int is fine here, as we're not going to utilize u64. Sorry, I just realized that extent_state in extent_io_tree can be merged with each other. So (state->end - state->start + 1) can overflow unsigned int. I'll skip this modification in next update, and apply the grammar comment. Thanks, Qu > >> /* Changed ranges */ >> struct ulist range_changed; >> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c >> index 9f01c25469f7..ad2e99491395 100644 >> --- a/fs/btrfs/qgroup.c >> +++ b/fs/btrfs/qgroup.c >> @@ -2886,6 +2886,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; >> -- >> 2.12.2 >> >> >> >> -- >> 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 > -- > 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 > > -- 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 05/17/2017 09:12 AM, Qu Wenruo wrote: > > > At 05/16/2017 10:23 PM, David Sterba wrote: >> On Fri, May 12, 2017 at 11:30:43AM +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/free_data() only returns 0 or a negative 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" >> ^^^^^^^^^ >> NO_HOLES or no-hole >> >>> 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(-) >>> >>> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c >>> index e390451c72e6..4f62696131a6 100644 >>> --- a/fs/btrfs/extent-tree.c >>> +++ b/fs/btrfs/extent-tree.c >>> @@ -4298,7 +4298,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 1eafa2f0ede3..cc1b08fa9fe7 100644 >>> --- a/fs/btrfs/extent_io.h >>> +++ b/fs/btrfs/extent_io.h >>> @@ -205,7 +205,7 @@ struct extent_buffer { >>> */ >>> struct extent_changeset { >>> /* How many bytes are set/cleared in this operation */ >>> - u64 bytes_changed; >>> + unsigned int bytes_changed; >> >> The alignment constraints will insert 4 bytes anyway, so we don't save >> any space, but unsigned int is fine here, as we're not going to >> utilize u64. > > Sorry, I just realized that extent_state in extent_io_tree can be merged > with each other. > > So (state->end - state->start + 1) can overflow unsigned int. Please ignore this comment. In context of btrfs_qgroup_reserve_data(), we won't modify ranges out of the data extent, which is no larger than 128M. And all related extent_changeset users are all based on actually allocated extent, so we won't overflow unsigned int any way. Thanks, Qu > > I'll skip this modification in next update, and apply the grammar comment. > > Thanks, > Qu > >> >>> /* Changed ranges */ >>> struct ulist range_changed; >>> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c >>> index 9f01c25469f7..ad2e99491395 100644 >>> --- a/fs/btrfs/qgroup.c >>> +++ b/fs/btrfs/qgroup.c >>> @@ -2886,6 +2886,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; >>> -- >>> 2.12.2 >>> >>> >>> >>> -- >>> 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 >> -- >> 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 >> >> -- 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 e390451c72e6..4f62696131a6 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4298,7 +4298,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 1eafa2f0ede3..cc1b08fa9fe7 100644 --- a/fs/btrfs/extent_io.h +++ b/fs/btrfs/extent_io.h @@ -205,7 +205,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 9f01c25469f7..ad2e99491395 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -2886,6 +2886,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(-)