Jeste je potreba pamatovat ze i radice (minimalne vsechny RAID radice) maji taky vyrovnavaci pamet a pokud ta neni zalohovana baterkou tak nam ani zurnalovaci FS nemusi pomoct. Proto ostry servery pouze a jen pres UPS (a pripadne i generator). Se selhanim HW se toho moc neda delat, proto i s UPS je tak baterkou drzena cache na radici nutna (aby data prezily i situace kde UPS nepomuze).
A neda se nahodou radici rict, aby zapisoval na disk co se mu rekne (write-through)?
Jinak UPSka je hezka vec, ale vetsina jich vydrzi jen par (nanejvys desitek) minut. Pak se musi budto zalohovat generatorem (coz nebyva vzdy jednoduche zrealizovat), nebo se musi pocitac sam rizene vypnout.
To nevim jestli se tem radicum da rict at necachujou zapisy, zas tak detailne sem se tim nezabyval...
A o tech UPSkach - tech par minut ti vetsinou staci k tomu aby si nastartoval generator anebo rizene vypnul server. V kazdym pripade se postara o to ze neprijdes o data diky vypadku proudu. A maj jeste hezkej side-effect, filtrujou napajeni, takze ani vykyvy v napeti (jak nahoru tak dolu) ti nebudou vadit tak jak by ti mohly bez ni.
Jasne, ale mit generator neni trivialni zalezitost :-)
Rizeny shutdown je taky pekna vec, ovsem ma (nebo alespon mel) jeden hacek - BIOSy maji nastaveni, co delat po zapnuti proudu a vetsinou tam byva(lo) jen "Vypnuty" a "Predchozi stav", tedy nikoli "Zapnuty". Takze kdyz se pocitac shutdownul, musel se nahodit manualne :-| (Coz tedy ma svoji logiku pri opakovanych vypadcich proudu, ale moc prijemne to stejne neni.)
Treba potom pocitac zahaltovat tak, aby sa nevypol ani nerestartoval, ale ostal stat - BSDcko ma shutdown -h (resp. halt), ked ho xcem vypnut, tak shutdown -p (tusim halt -p); v Linuxe neviem.
BTW taky BIOS som videl az jedenkrat, inak tam bezne vidavam "zapnut"...
> Při mountu filesystému se kontroluje žurnál. >Pokud je v něm nalezena transakce včetně commit >značky, tak se všechny operace náležející této >transakci zapíší na příslušná místa na disku. >Pokud je v žurnálu nalezena neúplná transakce bez >commitu, ignoruje se.
predpokladam, ze to robi cez automaticky start fsck...
>Žurnálování zajišťuje absolutní konzistenci >filesystému po výpadku
To hej ale co pri korektnom ukonceni?
Boot-ol som MDK9.0 v nom wmware a v nom ten isty MDK9.0 s tej istej particie a s priamym zapisom na disk (ext3). Oba korekne unmountly fs a ten bordel ste mali vidiet - fsck nabehlo nieco opravilo 8 balickov posahanych ale data ostali. Jedine, ze by bol problem v tom ,ze ten fsck zapisal transakcie v nekorektom poradi...
klasifikuje se todle jako FUD?
Díky tomu se v žurnálových filesystémech notoricky vyskytují bugy, které jsou většinou řešeny pravděpodobnostním způsobem (sám jsem na kernel mailing listu četl odpověď nějakého vývojáře ext3 na bug report o deadlocku: „v 2.4.18 jsme měli několik deadlocků, v 2.4.23 máme stále ještě jeden, ale tohle vypadá jinak, ještě se na to podívám”).
No je pravda, že třeba moje databázová aplikace (indexer FTP serverů) dává NTFS pořádně zabrat - tisíce fakgmenů u docela malých souborů :-(. Jenže ten oddíl, na kterém to je je z 95% zaplněný. A docela pochybuju, že by to na ext2 fragmentovalo méně. A taky se NTFS dá docela levně (za běhu) defragmentovat. Nevím, jaká je momentální situace, ale co si já pamatuji, tak defragmentace ext2 byla operace, při které se dotyčný oddíl musel u(n)mountovat.
No, ono to není _až_tak_blbě_. Pro šifrování se vygeneruje symetrický klíč a ten se asymetricky zašifruje zvláštním certifikátem uživatele určeným pro CFS. A uloží se 2x - jednou zašifrovaný klíčem uživatele a jednou klíčem administrátora, kvůli situacím typu přejetý uživatel.
Ujistuju vas ze hardlinky pouzivam a to casto. Spravne reseni - ktere mimochodem ext2 ukazuje u filetype - je cacheovat zakladni informace z inody v adresari. Pro informace ktere se daji menit by se to muselo delat jako optimalizace pouze pro jedno-linkove soubory, ale porad by se zachovala moznost mit hardlinky.