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).
Řídké soubory
Některá řešení (často databázové servery) potřebují vytvořit velký soubor, ale ještě nemají data, kterým by ho zaplnila. Řídké soubory (Sparse files) slouží právě pro tyto účely. Soubor se sice vytvoří velký, ale není fyzicky alokovaný a "díry", které v něm jsou, nezabírají zbytečně místo na disku.
Tak to je pěkný blábol. DB systémy si při vytváření souborů na disku (pokud nepoužívají raw device) alokují to místo kvůli tomu, aby ten soubor nebyl fragmentovaný. Ne pro to, aby fs mohl využít svoji skvělou funkcionalitu na šetřením místem.
Správně. Proto taky slušná databáze neudělá obrovský soubor plný nul, ale sáhne po funkci xfsctl a jejím příkazu XFS_IOC_RESVSP, který fyzicky vyhradí pokud možno defragmentované místo na disku pro určitý soubor.
Dik za tuhle reakci, usetrilo mi to spoustu psani.
Krom jineho bych rekl, ze autor volne micha vlastnosti JFS2 implementovane v AIX s Linuxovou implementaci.
K tem lockum - dokumentace je trochu jasnejsi:
JFS2 uses a read-shared,
write-exclusive inode lock which allows multiple
readers to access the file simultaneously, but
requires that the lock be held in exclusive mode
when a write access is made. This means that
when the lock is held in write-exclusive mode by
a process, no other process may access the file
for either reads or writes.
Jedna se o lock na urovni inode. K tomu dale:
However, in situations where the
contents of the inode may change for reasons
other than a change to the contents of the file
(writes), the inode lock is acquired in write-
exclusive mode. One such situation occurs when
a file is extended or truncated. Extending a file
may require allocation of new disk blocks for the
file, and consequently requires an update to the
“table of contents” of the corresponding inode.
In this case, the read-shared inode lock is
upgraded to the write-exclusive mode for the
duration of the extend operation. Similarly, when
a file is truncated, allocated disk blocks might be
freed and the inode’s table of contents needs to
be updated. Upon completion of the extend or
truncate operation, the inode lock reverts to read-
shared mode. This is a very powerful feature,
since it allows files using Concurrent I/O to grow
or shrink in a manner that is transparent to the
application, without having to close or reopen
files after a resize.
Kazdopadne clanek je jasnou ukazkou okurkove sezony, kdy je potreba zaplnit misto, klidne treba kompilatem informaci z wikipedie.
