----- Original Message -----
> Hi Nathan,
>
> No worries, I shall have a look and correct most of this things you have
> pointed out, some of them oversights on my behalf. Once the changes have
> been done I shall make some noise again.
>
Sounds good - feel free to send out small pieces as you make the changes,
then folks can review the changes as they come to hand.
>
> gfs2_refresh_lock_time is called for each file-system separately and the
(it doesn't have to be - you could split it into a for-all-filesystems
function, then a subsequent per-filesystem bit to post-process)
> device_id is used to map the results as they come from the trace_pipe to
> each file-system has been mounted.
>
> Yes it is true that the trace_pipe is emptied each call, but
> unfortunately the events are fired in no particular order so the current
> method was to save any data found for other file-systems in the list (or
> any other data-structure) between calls using the dev_id to distinguish
> what file-system the information belonged to. When the next file-system
That's OK I think (see above).
> called refresh_lock_time we would check the list for any stored data
> from previous runs, it seemed the best idea at the time for mitigating
> the chances of losing data. The trace-point's use the dev_id as their
I worry a bit that the next read will see more data, and trash the
results from the first read (from an earlier filesystem during the
current pmFetch)? However I think it will be solved by separating
the all-vs-individual-filesystem pieces as above. Hope so, anyway.
> I was hoping currently have just the worst glock for the call (and
> collecting a top 10 client side) but this can be changed to give the
> worst 10 for that fetch.
Up to you and the semantics you're after, but my initial understanding
(perhaps naively) was you'd keep top 10 glocks on each cluster node and
collate them from data across the whole cluster in the client tool. Up
to you, this sort of stuff can be a later refinement too, of course, if
it is desirable.
cheers.
--
Nathan
|