atom feed10 messages in net.sourceforge.lists.smartmontools-supportRe: [smartmontools-support] [PATCH 3/...
FromSent OnAttachments
Stephen M. CameronMar 15, 2010 7:30 am 
Stephen M. CameronMar 15, 2010 7:31 am 
Stephen M. CameronMar 15, 2010 7:31 am 
Stephen M. CameronMar 15, 2010 7:31 am 
Stephen M. CameronMar 15, 2010 7:31 am 
Christian FrankeMar 15, 2010 9:56 am 
scam...@beardog.cce.hp.comMar 15, 2010 11:41 am 
Alex KedaMar 15, 2010 11:47 am 
Christian FrankeMar 16, 2010 6:13 am 
scam...@beardog.cce.hp.comMar 16, 2010 8:33 am 
Subject:Re: [smartmontools-support] [PATCH 3/4] Introduce concept of an hba (mainly for HP Smart Array)
From:Christian Franke (Chri@t-online.de)
Date:Mar 16, 2010 6:13:38 am
List:net.sourceforge.lists.smartmontools-support

Stephen M. Cameron wrote:

On Mon, Mar 15, 2010 at 05:57:19PM +0100, Christian Franke wrote:

Hi,

Stephen M. Cameron wrote:

Hi Smartmontools people,

I'm looking at trying to improve smartmontools support for HP Smart Arrays a little bit and would like some feed back on what I'm doing, though at this time, I am sure you don't want all of these patches (as they aren't finished.)

Thanks for your contribution!

Thanks for the feedback, just what I was looking for. It will take me awhile to digest it, and it'll probably be a week or two before I can get back to looking at this.

The main problem I'm trying to fix is that before *any* command may be sent to smart array disks, it currently has to do a CISS_REPORT_PHYS, *every time* for *every command*, and this means it's talking to the hardware approximately 2x as much as it really needs to, which is really not cool.

Of course :-)

So, to avoid that there needs to be some way, at the time each disk object is made , to say, "by the way, here's your 8-byte LUNID so you don't have to look it up every single time." And you don't want each disk looking up its LUNID and caching it, because if you have, say 128 disks, then you're going to be doing the identical CISS_REPORT_PHYS 128 times, getting back identically the same data each time, once per disk. You want to do the CISS_REPORT_PHYS *once per hba* (smartctl) or *once per hba per polling cycle* (smartd), and re-use that data for all the disks. It's just not a per-disk thing.

A first simple step would be to add the LUNID info as a member to the linux_cciss_device class and update it in a new controller specific open() function. This would reduce CISS_REPORT_PHYS calls from "once per passthrough" to "once per device open" which is the same as "once per smartctl run".

A second step would be to add a cache of HBA->LUNIDs info as a static member of linux_cciss_device and query/update it in the open() function. A cache would be easy to implement by std::map.

If this cache should be cleared after a smartd polling cycle, we could add something like smart_interface::on_start/end_polling_cycle() and call these in smartd. This could reduce CISS_REPORT_PHYS calls to "once per hba polling cycle" and requires only trivial changes to smartd.

The current implementation abuses the smart array for the purpose of conforming to the existing smartmontools design. Or so it appears to me.

This is true. The CCISS code in os_linux.cpp is essentially a thin wrapper around the old C code which used the old interface (see dev_legacy.cpp and os_*.cpp except freebsd, linux, win32).

During migration of os_linux.cpp to the new interface, I did only the bare minimum, especially because I don't have access to all those RAID controllers for testing. http://sourceforge.net/apps/trac/smartmontools/wiki/DeveloperHowToMigrate

Thanks, Christian

------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev