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