A tentokráte z úplně jiného pohledu a snad už konečně po mnoha útrapách i naposledy. Několik předcházejících ze zdánlivě nekonečné množiny svých bezesných nocí jsem začal znovu věnovat otázkám dokonalé infrastruktury heterogenních enterprise i malých sítí a vedle konečného řešení relativně bezpečné a přístupné Samby a experimentům s Active Directory Samby 4 se mi do hledáčku pochopitelně dostalo i AFP a s ním spojené stroje času.
Znovu a opět snad naposledy ještě připomenu, že pro implementaci AFP pro jiné UNIXové systémy se používá Netatalk. Ten je často nainstalovaný i ve specializovaných a už přednastavených domácích NAS. Ale v souvislosti (nejen) s ním se dá všude po Internetu zjistit a i na vlastní kůži zažít, že z nějakého podivného důvodu se čas od času zálohy pokazí a Time Machine pak jen suše zahlásí To improve reliability, Time Machine must create a new backup for you. Je to pain-in-the-ass, oprava je sice možná, ale dá se zjistit, proč k tomu vlastně dochází? A proč se říká, že je to opraveno pro Netatalk verze 2.2.3 a vyšší?
Na to je potřeba se podívat trochu blíž. Netatalk není jedna samostatná služba, je to kolekce hned několika démonů najednou - ale zjednodušeně lze tvrdit, že pro drtivou většinu dnešních účelů pouze démonů dvou. Jeden se stará o samotná spojení a datové přenosy (afpd) a druhý udržuje databázi Catalog Node ID metadat (cnid_metad), která jsou nutná pro správnou činnost výsledných sdílených umístění, aby se mohla tvářit a chovat tak, jako kdyby byla umístěna na opravdovém HFS disku, přestože tomu tak ve skutečnosti není. Samo o sobě je to hodně důležité pro sdílení souborů, bohužel pro režim stroje času už tolik ne, neboť ten si na určeném úložišti vytváří kompletní sparsebundle image s opravdovým HFS (je tam tedy velmi vhodné použít options:nostat) - i proto by nemělo na souborovém systému cílového úložiště tolik záležet. Takový image se pak dále ještě vnitřně dělí na tisíce 8MB bands, díky čemuž lze snadno zavést inkrementální zálohování. Všechno je pak ještě podpořeno důsledným checksummingem. A přesto občas dochází k poškození.
Na místě jsou dvě úvahy.
- Zprvu se může zdát, že afpd je až tak výkonný, že cílový souborový systém nezvládá zapisovat zálohovaná data dostatečně rychle, a proto mu sem tam něco ujede. Po této naivní úvaze jsem se jal přezkoumávat svůj linuxový server s OS Debian Wheezy, balíčkovým Netatalkem 2.2.2 a softwarovým RAIDem s JFS. Pro poslední dva zmiňované je velmi vhodné, aby byl - a zvlášť s více fyzickými disky - použit deadline I/O scheduler, pro zvýšení rychlosti čtení lze pak ještě pro JFS nastavit příznak noatime. Žádná taková optimalizace ale nepomohla. Ideální by rovněž bylo, aby místo pro časovou kapsu plavalo na spolehlivějším místě, ideálně na nějakém copy-on-write filesystému, jakým může být například HAMMER, ZFS, nebo v případě Linuxu nedodělaný Btrfs. Přesto existují zmínky, že se zálohy poškozují na specializovaných NAS právě se ZFS a že tuhle chybu opravuje až Netatalk 2.2.3.
- Pro úspěšné zálohování je rovněž klíčová atomicita operací a nedoporučuje se, aby byl během zálohování sdílený zdroj používán ještě jinde. Vzhledem k tomu, že časová kapsa s jednotlivými zálohami bývá od ostatních sdílených dat celkem oddělena a že afpd pro každé spojení spouští samostatný proces, by k ničemu takovému docházet nemělo, výchozí BerkeleyDB (bdb) backend pro CNID tedy taky zdánlivě nepředstavuje žádný problém.
Debian ve všech variantách nemá k dispozici balíček Netatalku vyšší než zmiňované 2.2.2, takže přišlo i na pokusy ručně sestavit vyšší verze (2.2.4 a 3.x), dokonce i přímo poslední revizi z gitu, a hledat nějaké rozdíly. Bylo to trochu obtížnější pro integraci a odlaďování při kompilaci trvalo snad věčnost, ale na každý pád to ve výsledku nemělo pražádný smysl. Debian (testing a sid) se přenesl z verze 2.1 na 2.2 nejspíš pouze proto, že je v ní podpora AFP 3.3 nutná pro Lion a Mountain Lion a od té doby ani ťuk; dá se předpokládat, že až bude zase trochu víc updatován, rovnou přinese verzi třetí.
Když pak ale člověk nakoukne do oficiálního changelogu Netatalku a dohledá, jak vlastně v 2.2.3 opravili onu chybu, zjistí, že nijak. Pouze se tam píše, že kvůli chybám při komunikaci s CNID databází čas od času docházelo k tomu, že se celý sdílený zdroj pro zálohu jevil jako jen pro čtení, a proto se pak zálohovanému systému zdálo, že se image poškodil. Proto jen vyměnili defaultně používanou BerkeleyDB CNID databázi za trivial umístěnou pouze v paměti.
Z toho teoreticky plynou dvě odpovědi. Při poškození image během používání původní BerkeleyDB by nebylo nutné nechat opravovat image přes hdiutil, ale prostě a jednoduše opravit jen databázi nějakým db_recover na straně serveru a případně ho restartovat. Ale hlavně, pokud je tohle opravdu ono magické řešení, pak by i u 2.2.2 mělo stačit pro stroj času nastavit cnidscheme:tdb. Používání tdb je ale jaksi omezeno tím, že může skutečně pracovat pouze s jedním klientem, což tedy vyžaduje separátní časové kapsy - pro každý Mac OS X stroj v síti vlastní sdílenou kapsu s jedním jediným image.
Bylo by opravdu revoluční, kdyby teď už k žádných chybám nedocházelo. Bohužel až čas ukáže, zatím mohu říct jen to, že různé vzájemné používání dvou strojů zároveň zálohujících a předávajících si mezi serverem nějaká jiná data nevedlo k žádnému poškození, a to to běželo nějaké dvě hodiny. A pokud to fungovat zase nebude, tak už asi nezbyde než to vyhodit z okna.