[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



----- 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]