Hi all, In light of one response I got to my summary, as well as a bit of testing done since that time, I thought I should recap with a bit more info, to be more fair/accurate. My posting was regarding problems of poor performance observed when accessing (cp, ftp, netbackup) a large (130gig) file on an external raid5 disk brick connected to a sol8X86 box via an adaptec U160 SCSI HBA ; such problems were NOT observed when identical file access was performed against a "small" (50 gig) file on the same system. -> In my original summary, I whinged and moaned that "Sun ought to do something about the cadp160 driver". In fact, it is true that Sun can't do anything about this driver, since it is written & maintained by Adaptec. If, of course, sun felt like writing a replacement driver to usurp the function of cadp160, I wouldn't be unhappy, but I'm not holding my breath :-) [in fact, it was pointed out to me that based on my experience so far, there is no conclusive proof that cadp160 is the cause of my problems - which is true ; it is just one suspect on my list of candidates]. -> Since posting the summary, I upgraded the cadp160 driver from version 1.1.0 as bundled with solaris8X86 10/03 to the newest available driver (version 1.2.1, as downloaded from adaptec's website.) Performance for the "before" vs "after" for cp,ftp,netbackup are summarized: Performance of "cp between-2-slices-on-disk-array" for driver used 130gig file 50gig file ============================================================== cadp160 driver v.1.1.0 1.47mb/sec 4.7mb/sec cadp160 driver v.1.2.1 2.51mb/sec 4.7mb/sec (note that nothing else changed other than the cadp160 driver version) These ##'s suggest performance is still significantly slower for the same action against this large vs. small file ; however the driver update did appear to have some impact on performance. Further testing (still pending) is to swap in a different (Ultra40 adaptec HBA, which would use cadp as the driver (ie, a totally different driver that was written by Sun, I believe) -- and see if any difference in performance persists with manipulation of the large vs small file. For the moment, however, I've deleted this monster file and will probably leave further testing on the back burner, since we infrequently create such large files. The primary concern was that it represented a larger underlying problem that could result in other (more severe) problems. as an aside: deleting the 130 gig file took ~10 minutes, and for the duration of the process, the system was effectively "hung". In contrast, deleting the 50 gig file was effectively instantaneous and had no impact on system responsiveness. Not sure if anyone else has seen this behaviour or not ever. Great fun. Finally: as recommended by one respondant to my summary, I did submit a problem report to adaptec, who assure me that nobody has ever had this kind of problem. Yay. So. Hope this info is of slight interest to someone, if not now then maybe in the future. Thanks, --Tim Chipman _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Jul 22 14:49:47 2003
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:16 EST