From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 1 16:30:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD3C6F77 for ; Fri, 1 Feb 2013 16:30:52 +0000 (UTC) (envelope-from prvs=174407b200=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 633F068 for ; Fri, 1 Feb 2013 16:30:51 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001964739.msg for ; Fri, 01 Feb 2013 16:30:49 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 01 Feb 2013 16:30:49 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=174407b200=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk> From: "Steven Hartland" To: "Steven Hartland" , "Wojciech Puchar" , References: Subject: Re: HDD write cache Date: Fri, 1 Feb 2013 16:31:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 16:30:52 -0000 Investigating a bit more a device reset will also trigger the change so after changing the value you can use camcontrol reset to trigger the change to apply using e.g. camcontrol reset 0:0:0 While this is stated in the man for ada its not obvious that changing the sysctl without a reset won't work, so you might want to raise a PR about it. Regards Steve ----- Original Message ----- From: "Steven Hartland" > Looking at the cam ata code I can't see how those values would do > anything after booting. > > I suspect they should be loader only tunables with the current code > and cant be changed on the fly for a disk that's already been > registered. > > Try setting the values in /boot/loader.conf if you haven't already? > > You can check the actual status of the disk itself using:- > camcontrol identify ada0 > > Regards > Steve > > ----- Original Message ----- > From: "Wojciech Puchar" > >> after reading quite recent topics about disabling/enabling write cache, i >> tried to test in on desktop 3.5" drive >> >> kern.cam.ada.write_cache: 1 >> kern.cam.ada.read_ahead: 1 >> kern.cam.ada.0.read_ahead: -1 >> kern.cam.ada.0.write_cache: -1 >> >> i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were >> exactly no differences at all, and disk seems to do always write caching. >> >> Does that drive lie and ignore commands or i do it wrong? >> >> this is my disk. >> >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-8 SATA 2.x device >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.