Even w/o an exploit this can be prettier and more secure.
128 karma · joined October 14, 2010
Even w/o an exploit this can be prettier and more secure.
And there are many interesting stops between FFS/UFS and ZFS. And ZFS, even today, is not the best system to use in all scenarios, by some margin.
https://blog.koehntopp.info/2023/05/06/50-years-in-filesyste...
https://blog.koehntopp.info/2023/05/12/50-years-in-filesyste...
https://blog.koehntopp.info/2023/05/15/50-years-in-filesyste...
https://blog.koehntopp.info/2023/05/17/50-years-in-filesyste...
What you have here is commission fraud on behalf of the hotel against Booking.com, and if you call back Booking.com and tell them about it, they will set the hotel straight.
Or you get back to the hotel, tell them you understand how commission fraud works and if they are willing to split that commission (18%) half and half with you.
Apache has a little known module as part of the build, at least in Ubuntu: mod_md.
Use this, it is trivial to set up, and completely automated the Let's Encrypt workflow and renewal, no external stuff necessary. It is as simple as adding a few lines to the global config, remove almost all SSL config and restarting the server (twice).
For data warehouses this is a different story, but god help you if you are table scanning in OLTP context.
But this implies that all indexes will have to be regenerated, if they contain a column that is utf8 and will be converted. As they sort differently, this requires rebuilding the index from scratch. Depending on data size this can take measurable time and effort.
Reducing this to 3 bytes is still bad, but only half as bad as before.
Only MySQL 8 introduced innodb typed temporary tables (unlogged, even), so with MySQL 8 this is no longer a problem.
To zap a drive you ask it to securely drop the self-encryption key. The data will still be there, but without the key it is indistinguishable from random noise.
At 400 MB/s, you restore a terabyte in 45 minutes, and then you need to replay the changes that happened since the backup (in MySQL: replay the binlog), which will take aproximately another 15 minutes.
"One hour of MTTR or provisioning time per Terabyte of data at 400 MB/s sustained linear I/O speed" is a useful rule of thumb.
Having a replica that you can promote reduces that to seconds. Having a time delayed replica where you just roll forward the binlog reduces that to minutes.
You can work with modern databases without using replication, but that in most cases just shows you suck at operations.
TRIM is useful, it gives the GC important information.
TRIM is not that important as long as the device is not full (less than 80%, generally speaking, but it is very easy to produce pathological cases that are way off in either direction). Once the device fills up above that it is crucial.
That provides capacity, but also redundancy. Better redundancy than at the disk level - fewer resources are shared.
https://blog.koehntopp.info/2021/03/24/a-lot-of-mysql.html Here is how we run our datatbases.
Correct.
> Hardware level redundancy like raid1 seems useful because it simplifies handling a common failure case when a single HDD or NVME fails on a database server
Nobody needs that if your database does replicate. Cassandra replicates data. MySQL in a replication setup replicates data. And so on. Individual nodes in such a setup are as expendable as individual disks in a RAID. More so, because you get not only protection against a disk failure, but depending on deployment strategy also against loss of a node, a Rack or a Rack Row. Or even loss of DC or AZ.
Ethernet is absorbing all the features of other networking technology, and adding them to it's own perfection.
Today you'd rather use Arista 7060, 7050cx orJuniper 5200 as ToR. You'd not build 1:1, but plan for it in terms of ports and cable space, then add capacity as needed.
Almost nobody in an Enterprise environment actually needs 1:1, unlike hosters or hyperscalers renting nodes to others. Even then you'd probably being able to get away with a certain amount of oversubscription.
We then install SDS software, Cloudian for S3, Quobyte for File, and we used to use Datera for iSCSI. Lightbits maybe in the future, I don't know.
These boxen get purchased with 4 NVME devices, but can grow to 24 NVME devices. Currently 11 TB Microns, going for 16 or more in the future.
For local storage, multiple NVME hardly ever make sense.
It looks like this: https://blog.koehntopp.info/2021/03/24/a-lot-of-mysql.html
Traditional OLTP workloads do not tend to have the concurrency to actually saturate the NVME. You would need to be 40-way parallel, but most OLTP workloads give you 4-way.
Multiple instances per device are almost a must.
Flash can write blocks at a granularity similar to a memory page (cells, around 4-16 KB). It can erase only sets of blocks, at a much larger granularity (around 512-ish cell sized blocks).
The FTL will try to find free pages to write your data to. In the background, it will also try to move data around to generate unused erase blocks and then erase them.
In flash, seeks are essentially free. That means that it does no longer matter if blocks are adjacent. Also, because of the FTL, adjacent FTL are not necessarily adjacent on the physical layer. And even if you do not rewrite a block, it may be that the garbage collection moves data around at the PHY layer in order to generate completely empty erase blocks.
The net effect is that positioning as seen from the OS no longer matters at all from the OS layer, and that the OS layer has zero control over adjacency and erase at the PHY layer. Rewriting, defragging, or other OS level operations cannot control what happens physically at the flash layer.
TRIM is a "blatant layering violation" in the Linus sense: It tells the disk "hardware" what the OS thinks it no longer needs. TRIM'ed blocks can be given up and will not be kept when the garbage collector tries to free up an erase page.
For that you have time delayed replicas and of course backups. But time delayed replicas are usually much faster to restore than a backup.
2. STFU notifications, then carefully tune back in.
3. The feed is crap. Do not read the feed. Make a bookmark bar:
3.1 https://companyname.facebook.com/chat/t/<..> Chat link
3.2 https://companyname.facebook.com/notifications/hub/all/ Notification hub link
3.3 https://companyname.facebook.com/?sk=h_chr Feed, force-chronological order, for hard cases only
3.4 https://companyname.facebook.com/profile.php?id=<your id here> Link to your profile, to write notes et al
3.5 https://companyname.facebook.com/groups/?category=membership Group Overview. This is your cockpit, basically
3.6 https://companyname.facebook.com/saved Saved Posts. Because their search is crap.
Before the corp FB instance we had Wikis, Email, Mailing Lists, Jabber and an internal "Youtube" like Video Store. It all sucked.
With the FB instance, the awareness of what goes on in other parts of the company is much higher, the noise level is lower, communication is more timely and generally you feel less stressed out. Email numbers are down, mailing lists practically do not exist any more (except for machine communication such as commit messages), things organize neatly in FB groups, and you kind of automatically find the groups that are relevant to work. The Wiki hardly sees discussion any more, and is mostly documentation.
There are a lot of problems in Workplace by Facebook, mostly in the messenger product (no spatial metaphor, i.e. no rooms, only groups, being the largest). But in general it has been an amazing improvement on what we had before.