Re: HDD write cache
On Sat, 2 Feb 2013 01:19:50 +0100 (CET) Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: 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. I also noticed a drastic drop in throughput when I disabled the write cache, about a factor of 4 or 5. However, in my case every HDD supports NCQ (32 tags), but NCQ is not enabled on any HDD. Whether that's because the driver for my chipset (ATI IXP700 AHCI SATA controller) doesn't turn NCQ on or for another reason, I can't say. I looked at the man page for camcontrol but a mechanism to turn on NCQ in the HDDs didn't jump off the page. Does anyone know off-hand of a way to turn on NCQ in the HDDs, other than maybe modifying the driver? -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
HDD write cache
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) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: HDD write cache
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 woj...@wojtek.tensor.gdynia.pl To: freebsd-hackers@freebsd.org Sent: Friday, February 01, 2013 2:26 PM Subject: HDD write cache 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) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org 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 postmas...@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-unsubscr...@freebsd.org
Re: HDD write cache
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: 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 postmas...@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-unsubscr...@freebsd.org
Re: HDD write cache
Wojciech writes: 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) 1) See the other followups about making sure this change actually takes effect. 2) How, exactly, are you testing this? With Command Queueing enabled, (and assuming that it is working properly) you will not see any difference in speed with a casual test. Does ata(4) support your controller? Last time I looked, ata did not support NCQ. :-( So turning the write cache on/off gives a huge difference in speed. When ahci and siis came out, NCQ was so fast that it looked like the write cache was on. I had to write a special pathological test to be able to tell the difference between having the write cache on and using NCQ. I needed to verify that the write cache was really off so that my data was safe. In anything resembling normal use, NCQ with the write cache off is just as fast as having the write cache on. You really get the best of both worlds, speed and safety. Now all we need is NCQ support for all the controllers that have it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: HDD write cache
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 this proved your statement. will check it out at next reboot. Regards Steve - Original Message - From: Wojciech Puchar woj...@wojtek.tensor.gdynia.pl To: freebsd-hackers@freebsd.org Sent: Friday, February 01, 2013 2:26 PM Subject: HDD write cache 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) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org 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 postmas...@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-unsubscr...@freebsd.org
Re: HDD write cache
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 postmas...@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-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
