| Message ID | 20191217065240.5919-1-wqu@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs-progs: ctree.h: Sync the comment for btrfs_file_extent_item | expand |
On 2019/12/17 2:52 PM, Qu Wenruo wrote: > The comment about data checksum on disk_bytes is completely wrong. > > Sync it with fixed kernel comment to avoid confusion. > > Signed-off-by: Qu Wenruo <wqu@suse.com> LGTM. Reviewed-by: Su Yue <Damenly_Su@gmx.com> > --- > ctree.h | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/ctree.h b/ctree.h > index 3e50d086..9459adf1 100644 > --- a/ctree.h > +++ b/ctree.h > @@ -916,13 +916,16 @@ struct btrfs_file_extent_item { > u8 type; > > /* > - * disk space consumed by the extent, checksum blocks are included > - * in these numbers > + * disk space consumed by the data extent > + * Data checksum is stored in csum tree, thus no bytenr/length takes > + * csum into consideration. > + * > + * At this offset in the structure, the inline extent data starts. > */ > __le64 disk_bytenr; > __le64 disk_num_bytes; > /* > - * the logical offset in file blocks (no csums) > + * the logical offset in file blocks > * this extent record is for. This allows a file extent to point > * into the middle of an existing extent on disk, sharing it > * between two snapshots (useful if some bytes in the middle of the > @@ -930,7 +933,8 @@ struct btrfs_file_extent_item { > */ > __le64 offset; > /* > - * the logical number of file blocks (no csums included) > + * the logical number of file blocks. This always reflects the size > + * uncompressed and without encoding. > */ > __le64 num_bytes; > >
On Tue, Dec 17, 2019 at 02:52:40PM +0800, Qu Wenruo wrote: > The comment about data checksum on disk_bytes is completely wrong. > > Sync it with fixed kernel comment to avoid confusion. > > Signed-off-by: Qu Wenruo <wqu@suse.com> Applied, thanks.
diff --git a/ctree.h b/ctree.h index 3e50d086..9459adf1 100644 --- a/ctree.h +++ b/ctree.h @@ -916,13 +916,16 @@ struct btrfs_file_extent_item { u8 type; /* - * disk space consumed by the extent, checksum blocks are included - * in these numbers + * disk space consumed by the data extent + * Data checksum is stored in csum tree, thus no bytenr/length takes + * csum into consideration. + * + * At this offset in the structure, the inline extent data starts. */ __le64 disk_bytenr; __le64 disk_num_bytes; /* - * the logical offset in file blocks (no csums) + * the logical offset in file blocks * this extent record is for. This allows a file extent to point * into the middle of an existing extent on disk, sharing it * between two snapshots (useful if some bytes in the middle of the @@ -930,7 +933,8 @@ struct btrfs_file_extent_item { */ __le64 offset; /* - * the logical number of file blocks (no csums included) + * the logical number of file blocks. This always reflects the size + * uncompressed and without encoding. */ __le64 num_bytes;
The comment about data checksum on disk_bytes is completely wrong. Sync it with fixed kernel comment to avoid confusion. Signed-off-by: Qu Wenruo <wqu@suse.com> --- ctree.h | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)