Nemyslím si, že schnapps je ten důvod. Schnapps je založen na BTRFS. V něm snapshoty fungují tak, že se jen zaznamená aktuální stav i-node stromu. V podstatě se nejedná o žádný velký zápis. Jde o to, že když se následně udělá změna, tak namísto přepisu bloku se alokuje nový blok. V důsledku se jedná o stejný počet zápisů a vytvoření snapshotu je jen v podstatě poznamenání o jeho existenci. V důsledku tak takových snapshotů můžete udělat obrovskou hromadu než se dostanete na množství zápisů jen pro jeden update.
Nemám odpověď co z provozovaných služeb to mohlo způsobit. Nejsem si vědom, že by ani jedna z nich něco takového mohla způsobit. Tedy v případě použití se storage pluginem. Osobně mám kromě prototypů nasazené i dvě produkční Omnie a to ve větvích kde dostávají denně updaty a automaticky je aktualizují. Na 4.0+ se denně jedná o několik updatů a ani u jedné jsem zatím nezaznamenal problémy s MMC a to samé u ostatních v týmu. Jsme si vědomi, že to je problém a storage plugin byl pokus o podchycení tohoto problému. Na druhou stranu se nemusíte automaticky obávat a deaktivovat updaty a schnapps, dělají jen minoritní počet zápisů oproti například LXC, Majordomo, Pakon, Nextcloud a další.
Pro ty co chtějí zkoumat pak doporučuji sledovat cat /sys/block/mmcblk0/stat | awk '{print $7}' což je počet zapsaných bloků od startu systému. Můžete pustit následně různé operace a vidět jak moc ovlivňují toto číslo. Pamatujte, že systém má diskovou cache a že změny hromadí než je opravdu zapíše a to ovlivní vaše potenciální měření.