R. Stevens, in his famous book about programming in O.S. environment, taught us that when the syscall write's block size is comparable (or even equal) to the filesystem block size, the performances are the best. Lower write block size reduces performances, higher doesn't significantly increase them. This can be easily checked on "regular" filesystems, like ext2, ext3, ... on traditional spinning disks.

But it seems not to be true for solid state disks (SSD) with particular filesystem on it (in my case Apple's HFS). There's not any apparent relation between the two block sizes, and the best performances are reached far beyond the FS's blocksize; in my case FS's blocksize if 4096; best perf are reached beyond 10k of write's block size.

Is this known to be related to HFS and/or to SSD technology and how it is managed by MacOS ?

  • 1
    Could you give a bit more detail about how the tests are done (to disambiguate what you are testing). – ctrl-alt-delor May 23 '17 at 11:05
  • This may be off topic. However I will make a suggestion: maybe the devices block size also has an effect. SSDs have a very large underlying blocksize. – ctrl-alt-delor May 23 '17 at 11:06
  • best perf are reached beyond 10k of write's block size Not surprising, as SSDs are fast enough that the system call overhead of lots of smaller 4k write() calls is going to be measurably slower than fewer, larger write() calls. That's likely true even if the underlying blocksize is only 4k, and if the underlying SSD block size is greater than 4k, it should be obvious that it'd be true. – Andrew Henle May 23 '17 at 15:09
  • Hi Richard, the tests are done very simply by repeatedly call the write(...) syscall with a buffer of different size (the "block") in a small and really simple C program. Something analogous can be seen with dd (changing the value of the bs= parameter), but I use to avoid it as in the timing is included the time to copy the block from the source into the memory... and for many blocks this costs. – user1131951 May 23 '17 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.