Prosím jak mohu zjistit nastavení UFS ? Např. u odolnosti proti výpadkům elektřiny se to hodně liší, podle toho jaké žurnálování je zapnuté. Ale nevím jak to zjistit. Často se píše že UFS SU+J, bylo fuj, ale dost možná je to hlavně v bug v jedné verzi freebsd, což už bylo dávno opraveno. Někdo jiný si zase pochvaluje jiný typ journalování, ale nikdo jsem se o tom nenačetl nějaké shrnutí.
A pokud nepoužijí journálování vůbec, mělo by to znamenat, že oprava po výpadku bude trvat déle - musí projít vše, ale nekonzistence by nastat neměla a mělo by to být spolehlivější než oprava na pozadí s journalováním. Také je trochu lepší výkon.
Pokud jednou za deset let vypnout proud. Počítám s tím, že budu opravovat ručně a déle, ale nechtěl bych aby z dat byla fašírka. Pokud se několik posledních záznamů neuloží vůbec nevadí, ale nemělo by se poškodit nic předešlého.
tunefs -p /dev/device nebo tunefs -p /mountpoint
LolPhirae má pravdu v tom, že téměř žádný z těch režimů UFS (bez ničeho), UFS SU, UFS SU+J není tak odolný proti náhlým výpadkům hw nebo napájení jako třeba ext4 nebo ZFS.
Nejbezpečnější varianta z tohohle hlediska je UFS bez dalších povolených fíčur.
SU vzniklo kdysi primárně kvůli dvěma věcem - zrychlení metadatových operací s inody a rychlejší fsck, kdy to nekontroluje všechno. Ty metadatové operace se zrychlí proto, že se při zápisu dělá fs reordering a sdružuje je a řeší jejich závislosti. Hlavně na točivých discích s dlouhou příst. dobou to přineslo razantní zrychlení při operacích s mnoha soubory v rozsáhlejších adr. strukturách a zvýšení propustnosti při přístupu z více procesů.
Nevýhodou je pak to, že se to proti normálnímu orderingu v UFS ty operace zpožďují (klidně i desítky vteřin) a při náhlém výpadku to může ovlivnit hodně souborů, do kterých se zapisovalo.
SU+J je přidání fixního 16MB žurnálu pro metadatové operace (tváří se jako soubor .sujournal v rootu), který hlavně dál zrychluje kontrolu a opravu na větších úložištích.
Bohužel se může stát, když se správně trefíte (aspoň když jsem to před pár lety testoval), že zatímco s UFS máte zasažených pár posledních souborů, co se nedopsaly. S UFS SU je jich razantně víc a u SU+J jich značná část skončí úplně prázdných, což pravděpodobně souvisí s tím, že to fsck rychle vymete a ihned uvolní data.
Takže, jestli si pro váš workload řeknete, že nevadí delší fsck, a případný pokles výkonu nebude zásadní, tak vypněte SU (tunefs -n disable /dev/neco).
Ještě je tam další režim, geom journal. A to je ještě něco jiného, to udělá v podstatě virtuální zařízení (jako dm v Linuxu), kde se pak prování žurnálování na úrovni bloků. Filesystém je nad tím, všechny zápisy jdou přes žurnál.
Vždycky mi to přišlo jako hack, co ten primární problém moc neřeší.
Nicméně, jestli si to pamatuju dobře, tak s LolPhirae jsme o tomhle přesně mluvili. A já jsem trochu oponoval tím, že se sice je to dost blbé (a bylo by fajn, aby i FreeBSD mělo robustní ne-COW systém), ale prakticky vzato jsem žádné tragédie i po výpadcích s SU, kdy bych se z toho nedostal, něměl. Část toho je pravděpodobně klika, část je daná tím, že také hodně závisí na konkrétní aplikaci, jak přesně zapisuje. Jestli používá standardně page cache, nebo O_DIRECT příp O_SYNC. Jestli třeba sama nepoužívá fsync() nebo "jen" fdatasync() atp.
Když tam byla nějaká data, co jsem chtěl mít celá (třeba logy nebo malou db), tak jsem měl mountpoint s vynuceným syncem, což je samozřejmě trochu extrém, protože daň za to pak je, že je to líné jak vandrácká hůl.
Upřímně, za posledních pár let jsem na FreeBSD téměř vždy používal jen ZFS. To, že je součástí systému a plně integrované, mi přišlo jedna z mála výhod, které to má oproti Linuxu, a byl to také hlavní důvod nasazení FreeBSD jako takového.
A také si odhaduji, že to tak má většina uživatelů, což je možná důvod, proč UFS a řešení těch problémů nevypadá jak nějaká extra priorita.
Jinak vcelku extenzivní test ohledně odolnosti je třeba tady:
https://unixdigest.com/articles/battle-testing-php-fopen-sqlite-postgresql-and-mariadb-on-ffs-ufs-ext-xfs-and-zfs.htmlJá si pár let zpět dělal něco podobného, byť jen se simulovanými pády QEMU virtuálu s FreeBSD, OpenBSD a Linuxem. Používal jsem dd, případně něco, co jsem si narychlo spácal na testy. Ve smyčce to zapisovalo a modifikovalo soubory, věděl jsem kontrolní součty, takže jsem po opravě fs byl schopen rychle kontrolovat, jak to dopadlo. Zkoušel jsem různé variace přístupů, syncování. Dopadlo to víceméně stejně, jako v linkovaném článku.
Můj závěr byl, že v Linuxu to není třeba extra řešit, na FreeBSD pak ZFS. UFS bez SU jako bezpečnější volba, pokud nějakého důvodu nemůžu, nechci COW. OpenBSD strašně líné, neškláluje se, ale je konzistentní.
Poslední příspěvky