Date: Sat, 2 Feb 2013 01:19:50 +0100 (CET) From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: HDD write cache Message-ID: <alpine.BSF.2.00.1302020117500.402@wojtek.tensor.gdynia.pl> In-Reply-To: <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk> References: <alpine.BSF.2.00.1302011524480.43260@wojtek.tensor.gdynia.pl> <DF4C0697C59747BEBE5DF564E0B934EB@multiplay.co.uk> <72C01AB30B93443C8C6F1183A04BBE30@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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: <SAMSUNG HD501LJ CR100-10> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1302020117500.402>