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

Hi,

The forthcoming block reservations code is complex, but basically,
some writes are allocating spans of blocks as you say. Others are
not, for technical reasons. Later, the blocks within the reserved
span are claimed. These reserved spans of blocks become "no-fly
zones" for other processes which may also be reserving blocks and/or
allocating blocks _without_ a reservation.

In debugging this new code, I ran into cases where a process was
improperly allocating a block that had been reserved by another process.
I also ran into cases where the block allocation code failed because
of mismanagement of the free space numbers for rgrps. By adding the
rgrp address and free space info to the allocation trace point, I
was able to make a correlation between what was reserved and what
was actually allocated. Without the information, I couldn't tell
when blocks were being allocated (and/or free space number problems)
by processes that didn't hold a reservation.

Regards,

Bob Peterson
Red Hat File Systems


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