Date: Fri, 29 May 1998 16:49:56 -0400 (EDT) From: Simon Shapiro <shimon@simon-shapiro.org> To: tcobb <tcobb@staff.circle.net> Cc: "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>, Karl Pielorz <kpielorz@tdx.co.uk> Subject: RE: DPT driver fails and panics with Degraded Array Message-ID: <XFMail.980529164956.shimon@simon-shapiro.org> In-Reply-To: <509A2986E5C5D111B7DD0060082F32A402FACD@freya.circle.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29-May-98 tcobb wrote:
[ To the rest of the crowd : Is it OK for me NOT to help this guy? :-(( ]
> Despite pre-certification testing, something will be different when you
> have a failure in production. The difference in our case, I'm guessing,
> was that the array is now 60-75% full, and the OS version is different,
> and the system was under heavy access load, too. The original driver
> was an over-hacked version stuffed into 2.2.2, the newest driver IS
> better integrated, and actually faster, but obviously unable to handle
> the under-load failure situation in exactly the way we had it happen.
Your comments demonstrate ignorance in addition to lack of manners.
I wrote this driver, every line of it, with help from others, but I wrote
it. As such, it may help you realize that it was actually written on
2.2-CURRENT, migrated to 2.2-BETA, 2.2-STABle, and finally to 3.0-CURRENT.
Anyone who has written a FreeBSD (or virtually any Unix) SCSI HBA driver
knows that the initial size reporting is a BIOS or firmware reply to a call
from the kernel SCSI layer, not the HBA driver.
How full is the disk has nothing to do with what the controller firmware
reports to the kernel as to the configuration.
Before releasing a driver, my procedure is as follows:
a. Create a 26GB partition
b. Spawn 256 processes, each doing random read/write operation on a 2GB
area of the 26GB partition. At this point, the load on the system will
reach 140-400 (we run the tests against RAID-0 and RAID-1, the
performance differs)
c. NFS-mount a large partition from another system, also running DPT and
RAID arrays.
d. Spawn 16-64 processes, each doing:
find /NFS | cpio -H newc -ov -O /dev/null
At this point LA will climb to 800-900.
We run this test for 24 hours on UP, then 24 hours on SMP
We then do make release, cut a CD, scrap the test machines and install from
the CD. One test machine installs to an IDE drive, and uses the DPT array
for some of the filesystems. The other system boots off the DPT.
We then repeat the test above.
Following that, I install the driver on my various on-line machines. About
a week later, the code is released to a FreeBSD committer for inclusion in
FreeBSD. If you snatch a patch from my ftp server, it may vary from
useless to excellent. No way to tell by looking at it. These patches are
not solicited to anyone, but any legitimate user, intending to use the code
in a legal an moral way is welcome to it.
So your statement about over-hacked back port is abusive rude and patently
not the truth.
As I said, I am using the DPT drivers in a production environment and so
are many others. I am very anxious to help any FreeBSD user fix any
problem I can help with, be it DPT related or otherwise. Being abused is
outside the scope of what I consider helping others.
Simon
---
Sincerely Yours,
Simon Shapiro Shimon@Simon-Shapiro.ORG
770.265.7340
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980529164956.shimon>