ahci.ko in RELENG_8_2, what about atacontrol cap?
mav at FreeBSD.org
Sun Apr 3 14:07:41 UTC 2011
On 03.04.2011 14:03, Jeremy Chadwick wrote:
> On Sun, Apr 03, 2011 at 12:21:55PM +0200, Patrick M. Hausen wrote:
>> Am 02.04.2011 um 11:40 schrieb Jeremy Chadwick:
>>> You want "camcontrol identify adaX". DO NOT confuse this with
>>> "camcontrol inquiry adaX" (this won't work).
>>> identify = for ATA
>>> inquiry = for SCSI
>> Works perfectly, but I just noticed one really odd thing:
>> 1. boot without ahci.ko:
>> nas-pmh# atacontrol cap ad4
>> write cache yes yes
>> 2. boot with ahci.ko:
>> nas-pmh# camcontrol identify ada0
>> write cache yes no
>> Well? ;-) The system is a HP NL36 - I just found a couple
>> of articles mentioning that the default setting in the BIOS
>> setup was write cache disabled. I can check that in the
>> next couple of days when I take the machine back to the
>> lab (no monitor/keyboard at my home office).
>> I'd prefer a way to make sure write cache is enabled via
>> some tuning from FreeBSD. The disks are dedicated to
>> a raidz2, so from what I found around the net, write cache
>> should not pose a major problem. Of course, one will lose
>> _some_ data at a power outage - what I want to avoid
>> for home office use is a completely lost file system.
>> Losing the last time machine backup of my Mac is tolerable.
> I don't have an explanation for what you're seeing. I can't reproduce
> it on any of our Supermicro systems (ICH9R-based, backed by a multitude
> of disk types; Intel X25-M and X25-V SSDs, WD Caviar Black 750GB, 1TB,
> and 2TB, etc.).
> CC'ing mav@ who might have some ideas. I don't see anything in RELENG_8
> that looks relevant (just went through src/sys/dev/ahci's commit log).
> Alexander, disk type is here (Seagate ST32000542AS):
I've noticed that some RAID BIOS'es disable write cache on their disks.
ata(4) enabled cache in such cases, but CAM doesn't now. I'll take care
of it for ATA. For now you can manage it via `camcontrol cmd`.
More information about the freebsd-stable