Date: Tue, 15 Jan 2013 12:03:33 -0800 From: Dieter BSD <dieterbsd@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: IBM blade server abysmal disk write performances Message-ID: <CAA3ZYrACHLU-4OyhLdD%2BmfCDR_kubBg-AiVcopL-skqDurE7YA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
>>> 5120000 bytes transferred in 60.024997 secs (85298 bytes/sec) >>> mpt0: <LSILogic SAS/SATA Adapter> port 0x1000-0x10ff mem 0x9b910000-0x9b913fff,0x9b900000-0x9b90ffff irq 28 at device 0.0 on pci11 >>> mpt0: MPI Version=1.5.20.0 >>> mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) >>> mpt0: 0 Active Volumes (2 Max) >>> mpt0: 0 Hidden Drive Members (14 Max) >>> da0 at mpt0 bus 0 scbus0 target 1 lun 0 >>> da0: <IBM-ESXS HUC106030CSS60 D3A6> Fixed Direct Access SCSI-6 device >>> da0: 300.000MB/s transfers >>> da0: Command Queueing enabled >>> da0: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) >> That's a 10k RPM drive. >> 10000 ops in 60 seconds is practically the definition of a 10k drive. Assuming 1 op per rev. > if it takes one revolution for one write it means that write caching is > disabled. Disabling the disks's write cache is *required* for data integrity. One op per rev means write caching is disabled and no queueing. But dmesg claims "Command Queueing enabled", so you should be getting more than one op per rev, and writes should be fast. Is this dd to the raw drive, to a filesystem? (FFS? ZFS? other?) Are you running compression, encryption, or some other feature that might slow things down? Also, try dd with a larger block size, like bs=1m.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAA3ZYrACHLU-4OyhLdD%2BmfCDR_kubBg-AiVcopL-skqDurE7YA>