Autor si svuj pripadny honorar fakt nezaslouzi. Neco se tady uz zminovalo, zkusim shrnout:
- soubory plne nul po tvrdem resetu jsou zpusobene prave tim, ze XFS zurnaluje jen metadata. Ext3 naproti tomu umi zurnalovat vse (coz je pomale), zurnalovat jen metadata (coz ma stejny problem jako XFS), nebo zurnalovat jen metadata, ale pred tim provadet souvisejici operace nad daty (rezim "ordered", ktery je implicitni). Ordered rezim prave zajisti, ze po vypadku budou v souboru data i kdyz ne nutne konzistentni, tak aspon takova, ktera _nekdy_ nedavno v tomto souboru skutecne byla. Tento problem je ovsem vlastnost vsech zurnalovanych FS krome ext3/4, tedy i JFS. Pokud vim, vyvojari linuxoveho XFS uvazovali o implementaci ordered rezimu, ale aspon ve 2.6.26 jeste neni.
- RAID tomuto nepomuze, jen UPS a system ktery nespadne (hahaha).
- delayed allocation neni o tom, ze system uklada zapisovana data do bufferu a zapisuje je az to jinak nejde. Tohle dela skoro kazdy FS. Delayed allocation je o tom, ze _misto_ kam zapisovana data pujdou, se urci ne rovnou pri prevzeti dat jadrem od aplikace, ale az pri vylivani tech dat na disk. To umozni vic samostatnych operaci spojit do jedne velke (a nejlepe do souvisleho bloku na disku). Ext4 to ma taky, XFS tohle ovsem umel o nejakych 10 let driv.
- stalo by za to zminit, ze extent-based alokace je i u ext4 (a JFS a ReiserFS).
- ridke soubory jsou soucasti kazdeho nativniho UNIXoveho systemu odnepameti (no, aspon od Systemu V, mozna i od Systemu III).
- direct I/O podporuje i mnoho dalsich FS v Linuxu (vcetne NFS, pokud to zapnete v jadre).
- xfsdump/xfsrestore: skoro kazdy souborovy system (vcetne ext2/3/4) ma svuj dump/restore s popsanymi vlastnostmi (ukladani podle cisel inodu, atd.). Co naopak ma XFS navic je xfs_freeze(8): timto muzete docasne zastavit I/O na filesystemu tak, ze disk na kterem FS lezi je v konzistentnim stavu (i vcetne uzavrenych transakci v zurnalu). Cili pak treba muzete udelat LVM snapshot, ktery je na rozdil od jinych FS konzistentni, a tedy se s nim lepe pracuje.
- JFS superblocks: superblok(y) ma snad kazdy UNIXovy filesystem odnepameti. Nic noveho u JFS. Vice kopii superbloku mel uz UFS ve 4.3BSD, v Linuxu pak napriklad ext2 a novejsi.
- jak je mysleno tohle? "JFS běžně používá tzv. read-shared a write-exclusive. To znamená, že číst může ze souboru více procesů, ale zapisovat pouze jeden." Vzdyt je to nesmysl - to by ten FS vubec nemohl pod UNIXem fungovat. UNIXove programy bezne vyuzivaji (a SUS/POSIX vyzaduje) to, ze jim nikdo nestoji s pistoli u hlavy a nenarizuje "ted nesmis zapisovat, protoze zapisuje nekdo jiny". Ostatne zkuste si vytvorit soubor na JFS a ze dvou terminalu pustit "cat > ten_soubor" a stridave do obou catu neco psat. Normalne to funguje - aniz bych cokoli rikal, JFS (stejne jako kterykoli jiny FS pod UNIXem) nema problem s tim, kdyz vice procesu zapisuje do jednoho souboru.
Toz tak. Priste nechte psat o filesystemech nekomu kdo tomu rozumi (sorry, nemuzu to rict mirneji - spatny clanek je pro ctenare horsi nez zadny clanek).