I am not sure about how BBWIN is reporting its Windows client metrics; MrBig for Windows reports file system usage in the following format:
Filesystem 1k-blocks Used Avail Capacity Mounted C 15727603 8740006 6987597 55.6% /FIXED/C D 277225672 6502600 270723072 2.3% /FIXED/D
Limits:
Drive Yellow Red
D 70.0 80.0
C 70.0 80.0
Default 90.0 95.0
We have some clustered Windows 2008 servers that are using shared resources that are only referenced by their UNC paths - they do not have logical drive assignments. Was wondering whether this would cause any issues with the processing in do_disk.c section:
/* * Some Unix filesystem reports contain the word "Filesystem". * So check if there's a slash in the NT filesystem letter - if yes, * then it's really a Unix system after all. */ if ( (dsystype == DT_NT) && (*(columns[5])) && (strchr(columns[0], '/')) ) dsystype = DT_UNIX;
Where the columns[5] would be referring to the "Mounted" column in the MrBig output, and columns[0] would be referring to the Filesystem column. The above logic is not being performed as a block step against the overall client's disk output but rather on a line by line basis of the disk output. The first occurrence matched will flip the subsequent data processing flow from Windows based to Unix based even for subsequent disk lines from the same client.
My question is whether the presence of UNC only mounts would be represented with backslashes (\) with the BBWIN/MrBig/whatever Windows reporting modules or whether they may end up converted to forward slashes (/) and thus falsely trigger the dsystype switch. The only affect on the subsequent processing is whether the Filesystem column (Windows OS) is used for storing the diskname (and generation of the rrd file name) or the "Mounted on" column is used for the diskname (Unix OS). If the UNC representation can cause this false flip, then initial Windows disk lines that are using logical drive assignments would be stored and referenced using the one column reference and once a UNC line is encountered, then it and all subsequent lines (including logical drive assignment lines) would be using the other column reference convention. Things could get busy if the line order varies from time to time (i.e. addition/removal of a UNC resource); then a logical drive time stamped data line may go in at times as a "Filesystem" rrd file, other times as a "Mounted on" rrd file.
setupfn2("%s%s.rrd", testname, diskname);
As I don't yet have any clients installed in these clustered Windows boxes or UNC only mounts on other boxes, I don't know what the "Mounted on" column output would look like for the UNC resource. If BBWIN/MrBig/whatever are not reporting on UNC resources then that's going to be an (separate) issue for us too.
Possible fix if this is an issue:
Was wondering if all the Windows clients (BBWIN/MrBig/whatever) all reliable report the last column with the "Mounted" header tag and whether all the Unix/Linux/BSD variants report their last column with the "Mounted on" header tag. If so then maybe a better way to handle this is to run a check against the overall client disk msg block for the string pattern of "Mounted on" instead. Change do_disk.c section:
else if (strstr(msg, "Filesystem")) dsystype = DT_NT; else dsystype = DT_UNIX;
to
else if (strstr(msg, "Filesystem")) dsystype = DT_NT; /* This will trigger for Windows and Unix/Linux flavors */ else if (strstr(msg, "Mounted on")) dsystype = DT_UNIX; /* Assuming all unix/linux/BSD clients report with "Mounted on" and Windows clients only report with "Mounted" in their header line */