[Cluster-devel] [GFS2 PATCH] GFS2: Add rgrp information to block_alloc trace point

[Steven Whitehouse]

Hi,

On Thu, 2012-04-12 at 09:16 -0400, Bob Peterson wrote:
> ----- Original Message -----
> | All the bmap group tracepoints start with the device number, followed
> | by
> | the string bmap, the inode number and then the start/length of the
> | blocks, so I'd rather not change that, without good reason.
> | 
> | If we are going to add the rgrp information here, then it should be
> | done
> | later in the structure/string. I'm also wondering whether we
> | shouldn't
> | add some of the other fields as well... rd_free and rd_dinodes spring
> | to
> | mind as obvious candidates.
> | 
> | Since there is quite a lot of information in each rgrp, it almost
> | warrants its own tracepoint rather than trying to add it into an
> | existing one...
> | 
> | So I think that this probably needs some more thought,
> | 
> | Steve.
> 
> Hi,
> 
> I can reformat it to put the rgrp data later in the string.
> 
> The main reason I added that particular rgrp information was for
> the purposes of debugging the (future) block reservations code
> for file defragmentation. For that (future) patch I add a new
> trace point for block reservations. Adding the rgrp address and
> rd_free_clone to this trace point allow us to see a correlation
> between the decisions made by the reservations code and the
> actual blocks that are allocated as a result. While I agree that
> another trace point may be warranted for rgrp information, I'd
> rather keep the rgrp address and rd_free_clone in this trace point
> for that reason.
> 
> I'll see if I can rearrange the format to be more suitable.
> 
> Regards,
> 
> Bob Peterson
> Red Hat File Systems

I'm still confused though... the reservation is just a start/length
pair, so why do we need the resource group in order to match it up here?

The rgrp information is also available via the rgrp specific entry in
the glocks file too, so we can always get it that way if required,

Steve.