Tom Judge wrote:
Michael Worobcuk wrote:
Am 21.07.2007 um 00:18 schrieb Tom Judge:
Michael Worobcuk wrote:
Tom Judge wrote:
As for performance issues with the SAS5/i, there is a problem in
the controller. A work arround was created by Scott Long which
created a sysctl that could be set to cause the controller to turn
on the on drive write cache's. These changes where commited to
RELENG_6 on 2007-06-05 21:32:57 UTC.
...
Here is the original commit log:
scottl 2007-06-03 23:13:05 UTC
FreeBSD src repository
Modified files:
sys/dev/mpt mpt.c mpt.h mpt_cam.c
Log:
mpt.c:
mpt.h:
Add support for reading extended configuration pages.
mpt_cam.c:
Do a top level topology scan on the SAS controller. If
any SATA device are discovered in this scan, send a passthrough
FIS to set the write cache. This is controllable through the
following tunable at boot:
hw.mpt.enable_sata_wc:
-1 = Do not configure, use the controller default
0 = Disable the write cache
1 = Enable the write cache
The default is -1. This tunable is just a hack and may be
deprecated in the future.
I set mpt.enable_sata_wc to 1, as hw.mpt.enable_sata_wc is, AFAIK
not tunable in mpt_cam.c. This did not take any effect to the
performance. Is there anything else to change ?
Not that I know of, do you have SAS or SATA disks attached to the
controller?
yes, SAS.
In that case the above sysctl is not going to work for you as as the
name suggests it is only for sata devices.
For someone with a bit more SCSI experience than me: Could this be
solved by setting the WCE (Write cache enable) bit in the modepage (8)
on sas devices if it is not already set? The driver could make this
change on SAS devices during the topology scan in similar way to the way
it does for SATA devices?
There are absolutely no plans for the MPT driver to automatically change
WCE settings for SAS, FC, or SCSI drives. The hack that I put in for
SATA is exactly what it is, a hack. It gets around the fact that there
is no SATA layer within CAM yet and thus no way to send SATA commands
from userland like there is with SCSI/FC/SAS. That will be addressed in
the future. So yes, the proper way to handle this is via camcontrol.
With that you should be able to change the WCE bit both temporarily
(i.e. until the next bus reset or power reset) or permanently (i.e. in
NVRAM of the drive). Worst case scenario is the the drive doesn't
support permanent settings, so you write a simple RC script to run
camcontrol on each boot.
Scott
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
