On Fri, Aug 25, 2017 at 04:48:43PM +0300, Nikolay Borisov wrote:
>
>
> On 25.08.2017 16:13, josef@xxxxxxxxxxxxxx wrote:
> > From: Josef Bacik <jbacik@xxxxxx>
> >
> > While looking at a log of a corrupted fs I needed to verify we were
> > missing csums for a given range. Make this easier by printing out how
> > many bytes a csum extent item represents when using btrfs_debug_tree.
> >
> > Signed-off-by: Josef Bacik <jbacik@xxxxxx>
> > ---
> > print-tree.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/print-tree.c b/print-tree.c
> > index 5927ed3..a124c96 100644
> > --- a/print-tree.c
> > +++ b/print-tree.c
> > @@ -1103,9 +1103,15 @@ void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb)
> > case BTRFS_CSUM_ITEM_KEY:
> > printf("\t\tcsum item\n");
> > break;
> > - case BTRFS_EXTENT_CSUM_KEY:
> > - printf("\t\textent csum item\n");
> > + case BTRFS_EXTENT_CSUM_KEY: {
> > + u16 csum_size =
> > + btrfs_super_csum_size(root->fs_info->super_copy);
> > + u32 size = (item_size / csum_size) *
> > + root->fs_info->sectorsize;
> > + printf("\t\textent csum item bytes %lu\n",
> > + (unsigned long)size);
>
> Currently for a csum item we get:
>
> item 0 key (EXTENT_CSUM EXTENT_CSUM 1103101952) itemoff 16279 itemsize 4
> extent csum item
>
>
> Why don't you go one step further and print the covered range -
> it would be key.offset + size (the number you've calculated) And so you
> can print something like:
>
> item 0 key (EXTENT_CSUM EXTENT_CSUM 1103101952) itemoff 16279 itemsize 4
> extent csum item 1103101952-1103106048
>
> "extent csum item range %llu-%lly\n", key.offset, key.offset + size
>
Because real engineers do that math in their head.
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
