[PATCH] Add infrastructure for gathering statistics on SMB
todd.stecher at isilon.com
Thu Feb 5 16:50:21 GMT 2009
> -----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
> 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
> > wire protocols, including CIFS, and requires entry points into the
> > process for gathering interesting SMB message characteristics such
> > the per-command message size, command, sub-command, some specific
> > ioctls, response latency, and the connected identity. This patch
> > 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.
More information about the samba-technical