The disk file is memory mapped; that is the actual memory, now external to memcached. There's no flush at shutdown, it just gracefully stops all in-flight actions and then does a fast data fixup on restart.
So it does continually read/write to that file. As I said earlier you can create an "equivalent" to writing the file at shutdown by moving the file after shutdown :) On Sun, 1 Dec 2019, David Karlsen wrote: > Won’t the cache be written to file at shutdown and not contionously while > running? > > søn. 1. des. 2019 kl. 03:58 skrev dormando <dorma...@rydia.net>: > Hey, > > It's only guaranteed to work in a ram disk. It will "work" on anything > else, but you'll lose deterministic performance. Worst case it'll burn > out > whatever device is underlying because it's not optimized for anything > but > RAM. > > So, two options for this situation: > > 1) I'd hope there's some way to bind mount an underlying tmpfs. With > almost all container systems there's some method of exposing an > underlying > path, though I have a low opinion of Kube so manybe not. > > 2) It does just create two normal files: the path you give it + .meta > file > that appears during graceful shutdown. After shutdown you can copy these > (perhaps with pigz or something) to a filesystem then restore to in-pod > tmpfs before starting up again. It'll increase the downtime but it'll > work. > > I guess.. 3) For completeness it also works on a DCPMM dax mount, which > survive reboots and act as "filesystems". You'd need to have the right > system and memory and etc. > > -Dormando > > On Sat, 30 Nov 2019, David Karlsen wrote: > > > Reading https://github.com/memcached/memcached/wiki/WarmRestart it is > a bit unclear to me if the mount *has* to be tmpfs backed, or it can be a > normal fileystem > like xfs. > > We are looking into running memcached through Kubernetes/containers - > and as a tmpfs volume would be wiped on pod-recreation > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups "memcached" group. > > To unsubscribe from this group and stop receiving emails from it, > send an email to memcached+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/2ed07578-4aff-4704-83b1-3cd7d56de59f%40googlegroups.com. > > > > > > -- > > --- > You received this message because you are subscribed to the Google > Groups "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to memcached+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1911301854320.5300%40dskull. > > -- > -- > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to memcached+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/CAGO7Ob36THu%2BJTo3uxFMW6t6RV4BUQ38WMuUVUetY9TqGwDP7w%40mail.gmail.com. > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1911301923260.5300%40dskull.
