Comments on: Fsync Performance on Storage Devices

By: Yves Trudeau

Yves Trudeau — Wed, 20 Nov 2019 15:38:53 +0000

In reply to james. When I mention "drive write cache", it normally means the on disk write cache. Some SATA drives can cheat when the drive cache is enable. As of RAID controller write cache, this is only for the Dell PERC results and there, yes, the cache was set to "write back".

By: Yves Trudeau

Yves Trudeau — Wed, 20 Nov 2019 14:41:18 +0000

In reply to Anthony Monthe. I used a loop of 1000 so the reported time can be interpreted as ms per event.

By: Anthony Monthe

Anthony Monthe — Wed, 20 Nov 2019 04:52:05 +0000

Salut Yves,
Very great article.

But I would emit doubts your benchmark methodology.
Your Python script makes the job, but data collection isn’t good.

Here’s the time command’s output:

$ time sleep 1

real 0m1.005s
user 0m0.000s
sys 0m0.003s

Things are given in seconds and you seem to use it as milliseconds.

Furthermore, you time the entire script and Python as an interpreted language has a long startup.
This time depends of Python version, CPU, etc and just add a false overhead to your results.

Otherwise, I really love Python, really really, but its for-loops are slow,
So you may not expect to reach the best perfs from a Python loop.
You could time each I/O, but the whole thing may be affected by Python perfs.

Thank you again for this article

By: james

james — Mon, 18 Nov 2019 11:49:38 +0000

Hi Yves, does “drive Write cache enabled” mean “Write Back” in physical RAID please?

By: Tina Falk

Tina Falk — Fri, 05 Apr 2019 13:33:55 +0000

Used fsync.py and it was fantastic– thanks for the post on this code and storage device

By: Levita Bernardo

Levita Bernardo — Thu, 15 Nov 2018 03:11:16 +0000

You did a great job in here Yves! Thank you for this article.

By: Eduard Spiridonov

Eduard Spiridonov — Wed, 08 Aug 2018 11:30:26 +0000

BTW, postgresql has pg_test_fsync utility for years

By: Timur Solodovnikov

Timur Solodovnikov — Sat, 17 Feb 2018 07:24:30 +0000

Thanks, very good article.

By: Jacob

Jacob — Wed, 14 Feb 2018 20:56:48 +0000

I tested your fsync.py using our SAN HPE 3PAR StoreServ 8400 storage.
It is relatively high level flash-based storage device.
10 000 iterations took 19.303s or 1.903 ms per fsync (~ 518 fsyncs / seconds).

By: Yves Trudeau

Yves Trudeau — Mon, 12 Feb 2018 15:18:16 +0000

In reply to Franz Hänel. I did some research on my side and you are right, the optane appears to be safe in term of power loss. Quite impressive performance and a a cheap SLOG device.

By: Franz Hänel

Franz Hänel — Fri, 09 Feb 2018 17:11:58 +0000

In reply to Yves Trudeau. Well, it's without a volatile cache, so it shouldn't need power loss protection. https://www.anandtech.com/show/11953/the-intel-optane-ssd-900p-review/3

By: Yves Trudeau

Yves Trudeau — Fri, 09 Feb 2018 17:01:07 +0000

In reply to Franz Hänel. Be careful, although the Optane 900P has impressive specs, you'll find this in the specs: "Enhanced Power Loss Data Protection No". I wonder if it really persists the data at each fsync or fdatasync. I would be interesting to find out because it would be a very nice SLOG device.

By: jonathan

jonathan — Thu, 08 Feb 2018 22:11:41 +0000

Excellent post, Yves.

By: Franz Hänel

Franz Hänel — Thu, 08 Feb 2018 18:59:13 +0000

I tested your fsync.py using an Intel Optane SSD (900P 280GB, ext4). It took 0.054s to complete but it appears that some of that time was outside the for-loop. 10 000 iterations took 0.43s or 0.043 ms per fsync (~ 23 250 fsyncs / seconds).

And some ZFS benchmarks… https://www.servethehome.com/exploring-best-zfs-zil-slog-ssd-intel-optane-nand/