Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have an SSD installed in a PC. And the test tool is IOMeter. When using Centos 6.3 or Ubunut 12.04, the Random/4K/100% Read/64 Outstanding IO/s test shows about 8000 iops. But when testing in Windows 7 with the same setting. The iops is about 68000!

Even more surprising is: Random/4K/100% Write/64 Outstanding IO/s test shows 13000 iops on Centos/Ubuntu. Write is faster than read!

Can anyone tell why?

UPDATE: The SSD is Samsung 830 Series 256GB. The interface is 6Gb/s.

UPDATE: New test result. This time is much better.

Test under Centos 6.3


Raw / FS  |  Transfer size  |  Read / Write  |  Outstanding IO/s  |  IOPS
   raw    |       4K        |    100% read   |        64          |  ~22000
   raw    |       4K        |    100% read   |        1           |  ~16k-20k
   fs     |       4K        |    100% read   |        64          |  ~6200
   fs     |       4K        |    100% read   |        1           |  ~6400
   raw    |       4K        |    100% write  |        64          |  ~29000
   raw    |       4K        |    100% write  |        1           |  ~27000
   fs     |       4K        |    100% write  |        64          |  ~30000
   fs     |       4K        |    100% write  |        1           |  ~27000

UPDATE: Finally I found the answer: This issue is caused by IOMeter itself! It can not load the IO system at full capacity and the iops number is not correct as well! After using sysbench tool I can see the iops reach up to ~64000. Almost the same as WIN7 :)

share|improve this question

closed as not constructive by Zoredache, John Gardeniers, Michael Hampton, Tom O'Connor, Shane Madden Aug 17 '12 at 6:16

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Are you sure these tests are exactly identical across OSes? –  Michael Hampton Aug 16 '12 at 7:24
    
I think so. The only difference is that I can't see the raw disk in the "Disk Targets" tab of IOMeter when testing in Win7. –  fubupc Aug 16 '12 at 7:31
    
I just tested file system in Centos. The result is even worse... It has only 6000 iops. The file system mount options is defaults,noatime,discard. Actually I think the options is not related to READ test, right? –  fubupc Aug 16 '12 at 9:00
    
@fubupc Proof that Windows is the superior OS, clearly. :D Or do you think it could be related to driver differences between the two platforms? –  HopelessN00b Aug 16 '12 at 11:54

2 Answers 2

Some SSD firmwares are optimized for the access patterns of NTFS and FAT, but I'm unsure if this is the case here.

share|improve this answer
    
Thanks for replying! Actually when testing in Linux I'm using the raw disk in the "Disk Targets" tab of IOMeter. So I think it should be not related to file system? –  fubupc Aug 16 '12 at 7:29

This is most likely down to Windows having by default on hard disk's that support it Write-caching policy set to enabled. It will massively increase your write IOPs as you've seen in your test.

Just disable it for your Iometer test and you should see the same numbers as Linux.

share|improve this answer
    
Hum. Actually the 8000 vs 68000 iops is READ test! –  fubupc Aug 16 '12 at 7:44
    
@fubupc heh, not sure why I read it as write. It is still definitely caching of some description, just need to figure out what it is. –  M Afifi Aug 16 '12 at 7:48
    
Yes. I think maybe cache is the problem, but WIN7 can't test raw disk directly. And I think the iometer should be using some method to direct access through cache in WIN7 which the O_DIRECT flag do in linux? –  fubupc Aug 16 '12 at 9:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.