From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 2 00:19:53 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 634814C8 for ; Sat, 2 Feb 2013 00:19:53 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id D5C45793 for ; Sat, 2 Feb 2013 00:19:52 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r120Jo83007801; Sat, 2 Feb 2013 01:19:50 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r120JoIA007798; Sat, 2 Feb 2013 01:19:50 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 2 Feb 2013 01:19:50 +0100 (CET) From: Wojciech Puchar To: Steven Hartland Subject: Re: HDD write cache In-Reply-To: <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk> Message-ID: References: <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 02 Feb 2013 01:19:50 +0100 (CET) Cc: freebsd-hackers@freebsd.org 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: Sat, 02 Feb 2013 00:19:53 -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 THIS actually work. And the results are disastrous. in spite of NCQ working and fully filled, when unpacking source tree (as a test) onto UFS filesystem gstat shows at most 100 IOPS, and average 700 with write cache disabled. this is on / partition that spans 1/10 of disk. Drive can actually manage multiple writes in short distance well with write cache enabled. > > 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. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >