Vlákno názorů k článku Debian 9 Stretch je tu: firewall nftables a konec MySQL od MP - Do clanku bych pridal i tyto upozorneni: 1] jadro...
-
MP (neregistrovaný)
Do clanku bych pridal i tyto upozorneni:
1] jadro 4.9 a btrfs jsou by default problemove. Po upgradu jednoho zalohovaciho serveru dochazi k havarovani zalohovaciho systemu (puvodne bacula, nyni bareos) - (GFP_NOFS | __GFP_HIGHMEM | ....), tam, kde drive stacilo 6GB RAM, nestaci ani 16GB. Viz google "btrfs page allocation stall 4.9".
2] ta zmena sitovych nazvu krome smazani pravidla pro udev vyzaduje i update initramfs, jinak se to bude pri startu rozbijet, zvlaste v kombinaci s LACP.
-
. . (neregistrovaný)
"stabilnejsi linuxovy FS", zfs mám rád a používám mnoho let, na linuxu ho ale rozhodně nemohu označit jako stabilní, ne že by vykazoval tolik chyb, ale jeho nasazení je zatím minimální.
BTRFS používá třeba facebook a od něho je v upstreamu řada commitů, mají s ním také své problémy.
-
Na produkčním serveru je (většinou) nesmysl nasazovat cokoli tak složitého jako btrfs kvůli zmíněným featurám. Compress si má řešit aplikace, jen tak se zajistí, aby nedocházelo ke zbytečné degradaci výkonu. Když už by měl být compress na úrovni FS, tak by se to určitě dalo řešit pomocí layered FS nad prakticky libovolným FS. Snapshoty a CoW umí LFS. A stále mám volbu FS podle toho, co považuju za stabilní a co považuju za rychlé vzhledem k aplikaci pod kterou to provozuju.
All-in-one řešení většinou nepřitáhnou dost vývojářů a dost uživatelů na to aby se rychle stabilizovaly. Viz třeba systemd nebo networkmanager. Také se snaží řešit vše v jednom, a výsledkem je, že jsou v tom nacházeny stále nové chyby (nebo alespoň regrese proti stavu kdy nejsou nasazeny, vývojáři těchto systémů totiž často ani nemají sílu implementovat úplně všechny featury, takže v určitou chvíli začnou hledat chyby v dosud funkčních aplikacích). A naopak se pak najdou aplikace které zbytečně vyžadují konkrétní all-in-one řešení, protože vývojář nemohl vyzkoušet nic jiného (protože by musel vyměnit všechny vrstvy tohoto řešení).
-
MP (neregistrovaný)
A cim vyresite bitrot, send/receive? Dalsi vrstvou?
Je sice hezke, ze kompresi ma podporovat aplikace, ale pokud treba podporuje jen pomaly gzip, tak si s tim clovek moc nepomuze. Pak se vyplati mit kompresi na transparentni vrstve, idealne vsak vse v jednom, aby nebylo potreba ladit kazdou vrstvu extra a jeste kazdou vrstvu pripadne i monitorovat.
V dobe rozhodovani proste moc realne pouzitelnych moznosti nebylo. -
O checksumech nebyla v puvodnim prispevku rec. Na druhou stranu bitrot se muze stat i v aplikaci (mimo FS) a nasledne se ulozit. Na takto ridke chyby byva lepsi mit jednu odpoved dohromady: rozumne zalohy. Ty totiz musite mit kazdopadne (protoze programator aplikace kterou na tom provozujete take neni neomylny). No a pak si vycislete riziko bitrotu, vynasobte to zpusobenymi skodami a porovnejte to s rizikem a skodami zpusobenymi tim, ze se v btrfs jeste stale sem tam najde moucha (prevazne pokud vsechny zminene features aktivne najednou pouzivate). Me to vychazi tak, ze neni duvod k prechodu na btrfs, ale vase aplikace mohou byt napsane jinak.
-
. . (neregistrovaný)
jakákoliv chyba v FS (ať už v samotném kódu nebo ve spojení s jinou technologií) je skoro stopka pro provoz, špatně se ladí, špatně se sleduje, udělat opravu a recompilaci na produkční mašině je dost hard. Naproti tomu upravit nebo otestovat aplikaci je mnohem snažší, jednodušší a vývojové týmy s tím jsou za dobře.
Tvoje zmíněné problémy řeší specializované aplikace typu ceph, clusterfs, riak cs, hadoop atd. atd. atd. V Linuxu úprava nebo správa jakéhokoliv kernel modulu je problematická a velice složitá, lepší je se tomu vyhnout pokud k tomu nemáš sakra dobrý důvod, pak ale i tak nemůžeš čekat, že můžeš každý den nasazovat novou verzi.
-
Co to s těmi jádry najednou je? Na notebooku s Ubuntu 17.04 mi kernel 4.10 padal minimálně hednou denně, až jsem nakonec příslušné balíky downgradoval na 4.8 z Ubuntu 16.10 (od té doby je klid). Teď čtu, že tradičně superstabilní Debian pro změnu nasadil jádro, o němž se ví, že je zabugované... To už je pomalu jako Windows ;)
