Why is write faster than read?

[gearhead]

Below is a screen shot of DiskMark that I ran. As you can see writes (97.58 MB/s) are almost twice as fast a reads (55.22 MB/s). I thought writes are significantly slower than reads! Do you what could cause this? TIA

 

[neo_]

Your title is contradictory to your post.

 

[gearhead]

You are write, I don't know how change the title. It should be Why is writes are faster than reads.

 

[gpsguy]

Hopefully, a mod will fix the problem. I flagged the message.

 

[SweetAndLow]

Testing performance isn't as easy as running a test in a GUI that calculates read and write throughout. You have lots of variables that you need to eliminate or make constant. These include client machine, network, other activity on nas and zfs cache. Did you read the forum rules or other performance sticks? You should do that then come back with more information including your hardware spec.

 

[gearhead]

SnL, my hardware info is part of my signature. My question is not related to performance per se. My understanding of the physics of hard drives is that it is slower to write to them than to read from them. So when I ran the test I was surprised to see that the reads were slower than write by a factor 2 to 1.

 

[pirateghost]

What you have presented us is an application that runs on windows. How does this play into FreeNAS?

How are you presenting this share/disk to windows?

 

[SweetAndLow]

What you have presented us is an application that runs on windows. How does this play into FreeNAS?

How are you presenting this share/disk to windows?

This also goes with what i said about using that windows tool doesn't tell you anything about the performance of your NAS.

 

[gearhead]

I understand that I am using a windows application. My FreeNas server is used in a windows environment. So if CrystalDiskMark is reporting faster writes than reads does mean other windows apps experience the same.

 

[SweetAndLow]

No you can read and write at the same speed over the network. There is something on your client that is messed up or the workflow you are testing causes this behavior.

 

[pirateghost]

I understand that I am using a windows application. My FreeNas server is used in a windows environment. So if CrystalDiskMark is reporting faster writes than reads does mean other windows apps experience the same.

This sounds like you are saying that because of one arbitrary test that doesn't actually test your hardware, it applies to every workload?

This isn't how things work. You also never explained how you are presenting the storage to your clients.


Sent from my iPhone using Tapatalk

 

[gearhead]

PG, I am not assuming I am asking a question. I have very LITTLE unix knowledge. The clients (all two of them) are connected thru cifs as guests with no password requirement thru a gigabit switch.

 

[pirateghost]

PG, I am not assuming I am asking a question. I have very LITTLE unix knowledge. The clients (all two of them) are connected thru cifs as guests with no password requirement thru a gigabit switch.

But you've been told already that you are testing this whole thing incorrectly.

That program running on windows across a cifs share is not an accurate representation of the way the system works. But if you insist on ignoring the answers provided, I must step out of the conversation.

 

[Alvin]

Guys, please. The test is valid. It's what he gets when writing and reading in a more or less real world scenario. Ok, you're testing the network and some protocol as well, but there's nothing wrong with that.
The answer is probably cache.
Stands to reason. Writes are cached in ram on the FreeNAS server and therefore received fast. Depending on how the test works, reading from disk is slow unless the data was already in the cache before you tried to read it.

What cache? Well... I'm not burning my fingers trying to answer that.

 

[cyberjock]

No the test is not valid

Guys, please. The test is valid. It's what he gets when writing and reading in a more or less real world scenario. Ok, you're testing the network and some protocol as well, but there's nothing wrong with that.

There is if you don't know enough to understand those variables (and the user clearly doesn't).

The answer is probably cache.

Ok, probably. But is it for certain? How about you do some proper benchmarks and rule it out (or in) for 100%. My server doesn't run on "probably".

That's why the other 2 were saying what they were saying, and then left the conversation. It's also why I don't intend to say much more in this thread.

Either you have the knowledge and experience to understand that stuff, or you don't. We aren't really here to be a free education on all of the inner workings of the OS. We don't have the manpower to handle that kind of workload. ;)

 

[HoneyBadger]

Writes are faster because CIFS defaults to async and the 1GB test file is small enough to land 100% in RAM and consider itself "written" before the transaction group is spooled out to disk; you basically max out the network connection that way. (Impressive that you were able to hit 97MB/s sequential on a Realtek though.)

Reads can be impacted by ZFS trying to update metadata, concurrent writes, and cache misses.

Short version: That's what you should expect from CIFS on ZFS.

 

[gearhead]

Thanks everyone for you responses.