Okay, so here’s something interesting for you linux/mac os x geeks. I’m getting insanely fast results for DD tests on the Mac. i.e.
dd if=/dev/zero of=user_fs bs=1m count=1000 1048576000 bytes transferred in 19.193296 secs (54632409 bytes/sec) 52MB/s is not how fast this drive can write. In fact, it can’t even read that fast.
So what’s going on here? Looks like it’s doing a sequential buffered write, which for any drive is pretty quick, and looks to be exactly the same speed as buffered sequential reads. Essentially, if I am understanding this right, what we’re really seeing here is the maximum potential speed of this drive given the combination of computer speed and HD logic speed.
On linux it seems to be doing the same thing, with read and write speeds being essentially the same. Why do people use this as a test of HD speed? I can understand writing a large file to /dev/null to test read speeds, and that seems fairly accurate(i.e. reflects real world reads into memory), but DD doesn’t seem like a very good benchmark to me. In fact, when I do a “time cp file_i_just_created_with_dd /dev/null”, it takes longer to read it than it did to write.
But here’s something interesting. When I use DD to write to my RAID, I get about the same as a single drive, i.e. 55MB/sec. But when I do a cp of a large file from the RAID to /dev/null, I’m getting about 147MB/sec. I believe that’s an accurate number, which is one reason I’m dying inside that I can only get it to push over gig-e to my other machines at 15MB/sec. But I digress.
I don’t believe that DD, which seems to be essentially testing the theoretical maximum speed of my drives, is correctly measuring write speed to the RAID. I think that it’s really just working for one drive. Sooooooo.
I think what I’m going to need to do is use DD with something other than /dev/zero. I tried /dev/random which will hurt you a lot. /dev/urandom is not much better. They require far too much interaction from the cpu. So I’m going to just have to take a large file and use it as the source for dd instead of /dev/null.
So let’s make 1GB of random data with: dd if=/dev/urandom of=user_fs bs=1m count=1000 get some coffee now let’s do: dd if=user_fs of=user_fs2 bs=1m
This drops us into the much more realistic 25MB/s realm. But it also leaves us with a situation where we are both reading and writing to the same drive which could skew things. I don’t have 2 drives plugged into the machine I’m currently using to test, but I’m guessing it won’t be too far off of this one. This drive can read at 44MB/sec, so I can’t believe it’s working too hard to read and write at the same time.
I’ll do some more testing when I get to my other machine with multiple drives. But I think this is a better way to bench with DD for both reads and writes. I’ll run it on the raid at home, but the only other drive I have in there can only read at about 24MB/sec, so it’s not going to be much of a test.
I’m going to try the iozone tests and see what I come up with. I’ll keep you all posted as I can tell you’re riveted.