This is nice feature. I hope other software can write documentation in satirical form like Memcache. 
However redis is crash safe to about 1 second before crash or so, if not even better.
The parent poster's comment about redis being crash safe to 1s is just the default.
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?
PostgreSQL › wiki › Fsync_Errors
Fsync Errors - PostgreSQL wiki
LWN.net › Articles
PostgreSQL's fsync() surprise [LWN.net]
Lol interesting the way we used it at my last place of business was to restart the memcached server every 5 minutes (cron). Because as we know.... there are only really two hard problems in computer science. Naming things and invalidating cache :D
Why not write the system timestamp to the memory state file as well? And then "evict" (ie just not load) anything exceeding TTL on state file load?
To find out how long it was down, it notes system time into the state file on shutdown. On start it checks the current system time and adds the delta to the monotonic timer and resumes. Objects exceeding TTL are removed appropriately.
> (and of course, don’t futz with system time while memcached isn’t running).
Well, yes, that's what the original thing you quoted said: "Your system clock must be set correctly, or at least it must not move before memcached has restarted."
With the restart code, people could run a kernel upgrade and reboot while the daemon is down... so if this ends up causing a huge clock adjustment you're screwed.
I've had distributed systems perform unreliably in the < 30s range even with ntpupdate syncing in place.
"/tmpfs_mount/ must be a ram disk of some sort"
Curious if it really must be, or if that's just recommended for speed.
The alternative to 'must' is 'should', and people ignore that more easily, resulting in bug reports like 'memcached performance abysmal when running with disk', 'why does memcache cause 1MB of IO when I only read 256 4-byte keys', etc
But the worst case will be dismal and not unlikely.
The access pattern isn't optimized at all for flash or HDD or etc... however it does work super well if that mount happens to be a DAX mount over persistent memory.
I think the worst part is mmap-on-disk looks fine at first, and only comes out as a problem after you scale up a while. False sense of security. :/
If you have some kind of pmem device and a dax mount, those can survive reboots on their own.
Even with an optane pmem mount the perf. is super close.