Servers, Consistency, Blunders, OVH, OB2, CF SYN, fstrim

• Now got servers in Frankfurt with two operators in two separate data centers. Also with the C-Lion1 latency from Helsinki to Frankfurt servers is just about 20 milliseconds.
• Why you should pick strong consistency, whenever possible. Nice article about transactions and data consistency. Sure, everybody dislikes complex code. We've discussed this with colleagues over and over again. Simple and very badly performing naive code. Or much more complex, optimized smart code. But the fact is that the good code might contain 10x the lines of the simple code or even more. Allowing many more nasty bugs to creep in. A good example is simple LRU vs CLOCK-Pro caching. If you have to implement clock pro from the white paper, it's quite likely to be flawed in multiple ways. If concurrency isn't required for performance reasons, I very often use just single lock, running. And that's it. If my task is running, then nothing else should be done the the data. From the blog post the "Bounded stale reads" was a new term for me. They also mentioned "brittle, hard-to-maintain software with innumerable maintenance headaches", for sure that made me smile. It's nice that they also mentioned that complex code is also often buggy. True that. But it's especially fun when there are race conditions which happen extremely rarely, but causing major mess. That's the true joy. Because it happens so rarely, nobody wants to figure out what the problem actually is, and then the problem just keeps existing for extended periods. Yup, edge case experts, acknowledged. Back to that bounded-staleness, after thinking it for a while. It's obvious. If you know the time it takes data to replicate, providing bounded-stale read isn't a problem. Because it's known how stale the data is. Sure, that's better than 'eventual' which doesn't provide any staleness guarantee. I often use read committed for reads which will happen again, and I don't really care if the data is stale. Next run will check for it anyway. I do only use strong consistency mostly for read-modify-write cycles, where not using strong consistency would probably lead to nasty fails. I guess everyone have had their share of write skew.
• Read summary of biggest 2017 information security blunders. - Unsecured cloud storage & databases(S3 & MongoDB). Good joke, I've over and over said that nobody seems to care about that fact. It's business as usual. Worms, malware, ransomware and botnets creeping in via unsecured and unpatched systems. Whoo-hoo, no news. Yes, of course this applies to IoT devices too. But as stated, nobody seems to care about this either.
• OVH launched their Frankfurt, Germany (Actually Limburg / LIM1) data center. Already got some servers there.
• It seems that the latest OpenBazaar 2 code base contains lots of stuff which was missing one year ago. I wonder what they'll do, when the product is full featured and there's still the drive to endlessly add new features.
• Cloudflare SYN packet handling - Nice post. Nothing new. Yet some of the debugging tricks were stuff which I haven't ever needed personally.
• fstrim is now a lot slower that it used to be? Have they made it to behave nicer? Around at only 100 IOPS rate? My quick feeling is that that's the trick. Earlier fstrim used to generate absolutely huge IO spike.
• Lot's of discussion about Meltdown and Spectre and the overhead / inefficiencies, caused by the fixes. But this is a good question in general. How much faster if our systems could be, if we work in trusted environment with trusted data? There's huge amount of resources wasted on security. Yes, of course in some cases security is vital. But in other cases, performance is what's needed. Why doesn't the systems have options for high performance vs high security. In the good old DOS times, when you allocated file without writing to it, it just contained whatever data was on the disk at those addresses. Same applied to system memory. If you did memory allocation and didn't write to it, it has some existing data in it. Zeroing pages is also one extra wasted write cycle when allocating memory. And I'm 100% sure the list of this kind of waste is absolutely enormously long. Could we double the system performance in some cases, by dropping unnecessary isolation and security?

2019-05-05