On Tue, 2013-01-15 at 15:28 -0500, Karim Fodil-Lemelin wrote: > On 15/01/2013 3:03 PM, Dieter BSD wrote: > > 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. > Hi, > > Thanks to everyone that answered so far. Here is a follow up. dd to > the > raw drive and no compression/encryption or some other features, just > a > naive boot off a live 9.1 CD then dd (see below). The following > results > have been gathered on the FreeBSD 9.1 system:
You say dd with a raw drive, but as several people have pointed out, linux dd doesn't go directly to the drive by default. It looks like you can make it do so with the "direct" option, which should make it behave the same as freebsd's dd behaves by default (I think, I'm no linux expert). For example, using a usb thumb drive: th2 # dd if=/dev/sdb4 of=/dev/null count=100 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.0142396 s, 3.6 MB/s th2 # dd if=/dev/sdb4 of=/dev/null count=100 iflag=direct 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.0628582 s, 815 kB/s Hmm, just before hitting send I saw your other response that SAS drives behave badly, SATA are fine. That does seem to point away from dd behavior. It might still be interesting to see if the direct flag on linux drops performance into the same horrible range as freebsd with SAS. -- Ian _______________________________________________ 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"
