Don't use it in case of a fire

Given the rate at which we are progressing on SSD endurance, these methods will become irrelevant. Even 5 years back, the old tech report article showed that for an average user, they could handle a lot of writes.

https://techreport.com/review/27909/the-ssd-endurance-experi...

That winner of that test, the 840 Pro, uses 2-bit (MLC) cells.

Nowadays, 3-bit (TLC) and 4-bit (QLC) are much more common (not sure QLC even existed back then). So whilst each of these technologies has matured, the drive a consumer may consider today is more likely to be bigger, replacing their HDD entirely, and will probably be capable of fewer writes than an MLC drive from 5 years ago, iiuc.

MLC->TLC transition decreases endurance but 2D->3D transision increases much endurance. Current 3D TLC drives handles more TBWs compared to old consumer 2D MLC drives. So industry going to make QLC chips.

The drives also include more software and more excess capacity to mitigate the problem (except for the cheap ones)

The best ssd in that test lasted for writes ~1000x its capacity. Without a good wear-leveling SSD controller, you would see data loss in a day or two on e.g. log files. A good controller will never be irrelevant.

As has already been said, bash brace expansion is quite powerful. It has many usecases, such as,

  diff file{.original,}
  mkdir -p path/{a,b,c}/folder
  for i in image{001..060}; do echo $i; done

Parameter Expansion is also equally useful, like changing a few characters in long names,

  mv ${i}.png ${i/imaeg/image}.png

I have been using duckduckgo on all browsers, including mobiles, for 2-3 years now. There are occasions when I don't get good results. But when I try the same query on G, the results are equally useless. So, I have since stopped using anything else.

Although, I should say, bing was equally good when I used it before duckduckgo, until they added that horrendous news feed in the bottom.

This is great! In my case, only reason for choosing Redis over Memcached was persisting to disk. With memcached being multi-threaded compared to Redis being single-threaded, I see a big win in simple use-cases for Memcached.

The way i understand it, it is not crash safe. It can now persist data in some cases.

However redis is crash safe to about 1 second before crash or so, if not even better.

With fsync_always it's crash safe for all but the most pathological scenarios.

But it's performance is way worst, almost voiding the case for choosing Redis.

I have not found this to be true. I suppose it depends on your use case and deployment.

How? It's persisting to a RAM disk. It only properly cleans up when sent a specific shutdown signal.

Sorry fsync_always is a redis setting, not memcached. The fsync is to a real disk.

The parent poster's comment about redis being crash safe to 1s is just the default.

I do wonder what happens when a process writes to a memory mapped file, but crashes before the page is synced to disk. Does the write disappear?

If the OS is still alive, everything is ok (but the OS may sync different pages at different times and in any order if you don't fsync specific ranges with special calls). If the whole machine crashes (power issue, kernel panic, ...), what you find on disk can be a mess.

> what you find on disk can be a mess

Is this "can be" determined by the backing filesystem? E.g., would you expect to get a clean result from a log-structured or copy-on-write filesystem?

I prefer to architect to use redis in an ephemeral way. Redis isn't exactly safe in the same way postgresql was up until very recently on newer linux. The semantics of fsync on Linux have been esoteric and poorly understood in the error cases. I would try to cause fsync to fail in another process, while memcached is shutting down and immediately recover. I wonder if the authors checked this scenario. Redis kindof does the right thing and will eventually put the right thing on disk but why do it?

What issue caused postgres to not be safe recently?

Fsync doesn't work the way you think it does

https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...

PostgreSQL › wiki › Fsync_Errors Web results Fsync Errors - PostgreSQL wiki

LWN.net › Articles PostgreSQL's fsync() surprise [LWN.net]

Note that that only was an issue in cases the storage system itself was failing (i.e. IO errors were generated). In contrast to protection against power failures etc, which was/is working correctly.

Uhm the first sentence is accurate. The second is not

I'm fairly sure I was accurate. What exactly are you referring to?

Sharding is a fairly easy path to scale redis writes out across multiple processes/cores.

I look forward to read this. Thanks for posting the link.

> "You might well ask why you should study assembly language, given that I think you should avoid writing in it. I believe very strongly that the best programmers have a good understanding of how computer hardware works. I think this principle holds in most fields: the best drivers understand how automobiles work; the best musicians understand how their instrument works; etc."

There are new feature phones available in the market, with the benefits of modern technology such as better display, keyboard, battery.. Its probably not advertised much, but it is still there, and very much available.

We can never fix the "Referer" header, and we have accepted it! So, why not accept 418 for what it is ? Let it at-least complete its 20th year.

HTTP/1.1 418 I'm a Teapot

I think, he explains it early in the article,

"The problem with ethernet addresses is they're assigned sequentially at the factory, so they can't be hierarchical. That means the "bridging table" is not as nice as a modern IP routing table, which can talk about the route for a whole subnet at a time."

Browsers should just s/.feedback/.com/, problem solved.