1

As long as I know - IOps is a IO operations per second on a given data block. But size of that given block if often omitted.

I assume, that block size does not make difference as long as its relatively small and I can compare iops requirements for some software with iops performance of a storage system given by the manufacturer. Am I right?

And where is a limit for block size to be relatively small? Is 32k, for example, already too large?

Vasilly.Prokopyev
  • 173
  • 6

1 Answers1

1

Best block size depends on your application and use pattern. In general sequential access profits from large blocks (less reads needed), random access from small blocks (less wasted partial reads), but that is not set in stone.

Straight IOPS comparisons are mostly a marketing strategy/advertisement, if the test circumstances are not completely made public or specific versions of comparison tools are used. You have to fix the variables that do not interest you and then compare the results. I think it is difficult to reproduce all test settings that potential customers would need, and also if you publish everything, your competitor might cheat and compare his best results to your worst, so they just publish either best or average scores.

Usual block sizes are from 512 B to 128 KB, but the limits depend on the used file system, operating system and application software.

user121391
  • 2,502
  • 13
  • 31
  • My application uses a very large sequental blocks in a units of megabytes. But there is many threads reading and writing simultaneously. Can I take it as a sequential access? – Vasilly.Prokopyev Nov 02 '16 at 09:17
  • @Vasilly.Prokopyev It depends a bit on the filesystem and the optimization strategy (or lack of it). If your disk blocks all other threads for N seconds (round robin), I would see it as sequential, but others might disagree. If you have a CoW (copy on write) file system, you profit from the fact that all new and changed blocks are written on the end of the current last block, so even random writes become sequential (oversimplified, but you get the idea). – user121391 Nov 02 '16 at 10:44
  • @Vasilly.Prokopyev That is also the reason why you need to test with real data. Synthetic benchmarks are good to rule out things that really do not work or spot big problems, but afterwards you still need to test with real data (your old data for example) to give you a comparison. If a vendor does not want you to test with your data, I would rule him out on the spot. I would also compare your results of the vendors against your old system and against free/open alternatives like ZFS to give you a better estimate (also it allows you to throw better hardware at the same problem because it's free) – user121391 Nov 02 '16 at 10:51