GNU/Linux >> Znalost Linux >  >> Linux

Fsck nebo ne fsck po 180 dnech

Řešení 1:

Výchozí 180denní čas fsck je řešením chyby v návrhu, že ext3 nepodporuje online kontrolu konzistence. Skutečným řešením je najít souborový systém, který toto podporuje. Nevím, jestli to dělá nějaký vyspělý souborový systém. Je to skutečná tragédie. Možná nás btrfs jednoho dne zachrání.

Na problém s překvapivým mnohahodinovým výpadkem z fsck jsem zareagoval tím, že jsem v rámci standardní údržby provedl plánované restarty s plným fsck. Je to lepší, než se během výrobních hodin setkat s drobnou korupcí a nechat ji proměnit ve skutečný výpadek.

Velká část problému spočívá v tom, že ext3 má nepřiměřeně pomalý fsck. Ačkoli xfs má mnohem rychlejší fsck, používá příliš mnoho paměti pro distribuce, aby standardně podporoval xfs na velkých souborových systémech. Na většině systémů to však není problém. Přechod na xfs by alespoň umožnil přiměřeně rychlý fsck. To může usnadnit plánování spuštění fsck jako součásti běžné údržby.

Pokud používáte RedHat a uvažujete o použití xfs, musíte si dávat pozor na to, jak silně odrazují od používání xfs a na skutečnost, že pravděpodobně jen málo lidí používá xfs na jádře, které používáte.

Chápu to tak, že projekt ext4 má za cíl alespoň trochu zlepšit výkon fsck.

Řešení 2:

Řekl bych, že je to jen další důvod, proč by produkční servery neměly běžet úplně samy a vždy mít buď horkou/studenou zálohu, nebo se podílet na clusteru se dvěma uzly. V dnešní době virtualizace můžete snadno mít fyzický hlavní server a virtuální server, který je pouze kopií fyzického hotového každých X dní, připravené k převzetí.

Kromě této nepříliš užitečné odpovědi bych řekl, že byste měli vyvážit důležitost svých dat... Pokud se jedná pouze o uzel clusteru, přeskočte to. Pokud se jedná o nezálohovaný webový server klienta, možná budete chtít příště plánovat dopředu :-)

Řešení 3:

Závisí... Například nám vypadl jeden server kvůli běžné údržbě, na kterém běžel QMail stack. QMail postupem času vytváří a zabíjí spoustu souborů a byl to velmi zaneprázdněný poštovní server. Fsck trvalo nějakých 36 hodin. Není to tak, že bychom díky dohodě ušetřili zatraceně mnoho výkonu, ale nakonec předpokládám, že byste mohli tvrdit, že souborový systém byl zdravější. Opravdu to stálo za chaos, který nastal? Ne. V. Vše.


Linux
  1. Jak automaticky vynutit Fsck disky po havárii v `systemd`?

  2. Služba MongoDB se po počátečním nastavení nespustí

  3. eth0 se nespustí při startu po klonu Virtualboxu

  1. Proč dlouhé zpoždění poté, co příkaz nebyl nalezen?

  2. Jak obnovit data Xfs po Rm?

  3. Linux – po havárii Fs a spuštění Fsck byly některé soubory obnoveny, ale nebyly umístěny do ztracena a nalezeny?

  1. Proč Wget nezemřel po ztrátě připojení Ssh?

  2. Zvuk po instalaci 12.04 nefunguje?

  3. Pozastavení nefunguje po aktualizaci na Ubuntu 14.04 z 13.10?