[PATCH] Add infrastructure for gathering statistics on SMB messages

[Todd Stecher]

> -----Original Message-----
> From: Volker Lendecke [mailto:Volker.Lendecke at SerNet.DE]
> Sent: Thursday, February 05, 2009 12:56 AM
> To: Todd Stecher
> Cc: samba-technical at samba.org
> Subject: Re: [PATCH] Add infrastructure for gathering statistics on
SMB
> messages
> 
> Hi, Todd!
> 
> On Tue, Feb 03, 2009 at 05:32:00PM -0800, Todd Stecher wrote:
> > Isilon has a centralized performance monitoring system for all of
its
> > wire protocols, including CIFS, and requires entry points into the
SMBD
> > process for gathering interesting SMB message characteristics such
as
> > the per-command message size, command, sub-command, some specific
> > ioctls, response latency, and the connected identity.  This patch
adds a
> > pluggable module system to gather that data.
> 
> In general, I like that idea a lot. Two points though:
> 
> Quick question: Why couldn't you extend the existing
> (probably really bit-rotten) profile stuff under profile/?
> To me it seems that this at least has similar goals,
> although with some different information.

Yeah - I considered going that route multiple times - the main reason I
didn't refactor the profiling code is because, without a complete
rewrite, it didn't have the abstraction or granularity I needed, didn't
track the lifetime of individual requests, and it contained too much
mandatory state in user space - state which wasn't really relevant for
Isilon's scenario.  Also, it tracked a bunch of syscalls, etc, which I
wasn't interested in.  Could it be reshaped to meet my needs?  Yes :),
but at the end of the day it seemed like the two systems were too
disparate to be joined together.

I was looking for something more surgical - the patch simply produces
SMB messaging data, and then allows the consumer to use that data
however it wants.  In the Isilon case, it stores a couple of words of
information, and does all of the more complicated statistics calculation
in the kernel.  Other consumers may chose to do something closer to what
profiling does - calculating larger scale statistics in share memory.


> 
> Another thing: Can you add a module that outputs information
> similar to the existing profile/ code (not that I have used
> that in years). If we get that, IMO we could dump the
> existing stuff and replace it with something actually
> supported and used. Ideally, this would use the perfmon
> registry code.
>

Seems like a legitimate approach - I hope this isn't a condition of
patch approval, because I've been working 60 hours a week for a couple
of months now, and I'm *still* behind...  2 simultaneous projects to
complete + another that is supposed to start yesterday!  Fortunately,
its pretty cool cutting edge code.

Later,
Todd