LE_746F6D617A7A69 wrote:@pylkko: it looks like You're a BTRFS fanboy - that's OK, but I'm not going to play that game. The tests on Phoronix, although incomplete, are showing what's the problem ...
I'm a fanboi of "the larger the claims, the better the evidence needs to be". When you hear that people say stuff like "using this tech is a total stupidity", or "it is deadly slow" you start to wonder how on earth they determined this one tech to be so totally unusable.
About those tests on Phoronix... we could also look the rest of them. Like the latest one where btrfs outperforms ext4 in many things, one of which, by the way, was SQlite databases.
https://www.phoronix.com/scan.php?page= ... tems&num=1
This makes it even more interesting that your databases are performing poorly. There are probably some additional factors at play...
LE_746F6D617A7A69 wrote:
Throughput has nothing to do with the latency, unless the I/O bandwidth limits are reached ...
Then why did you start to talk about theoretical throughput in MB/s when the guy asked about the latency?
As throughput and latency are often correlated (on the implementation level, like comparing different storage technologies), it seems quite an over statement to say "they have nothing to do with each other". But they can "decouple" in some situation. One such situation probably is the use of transparent compression. Apparently a btrfs partition using transparent compression can move a large file (if it compresses well) much faster than a partition without (for example ext4) with the processors of today. But, this will come with a latency cost, since the device needs to move a block and let the CPU compress it before even the first bit can be transferred. If you are doing latency sensitive work, these kinds of issues you would think about, no?