Názory k článku
XFS a JFS: Odstrčené souborové systémy?

takze v linuxu je JFS1?

JFS je asi nejslabsi casti AIXu, meli by koupit licenci pro ext3 nebo ZFS nebo veritas.

Jenže nejslabší částí _celého_ systému jsou stejně ve výsledku špatně napsané aplikace. FS už to nezachrání.

A myslis si, ze na aktualnich AIXech se pouziva JFS1 nebo JFS2 ?

Doporucuji si radeji precist http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.baseadmn/doc/baseadmndita/fs_jfs_jfs2.htm nez placat v diskuzich ;-)

no my mame na AIXu JFS2 pac je to v petce default. Je to ale hroznej fs pro ukladani malych souboru. ext3 je mnohem lepsi.

"techniky pro zabránění defragmentace"?! O_o

>>Jedná se o serverový souborový systém, takže podpora sdílení dat přes SMB, CIFS a NFS je samozřejmostí

Tato veta mi vylozene pripada jako prelozena automatickym prekladacem, nebo proste prevzata z jineho zdroje, aniz by se autor hloubeji zamyslel. BTW Sambe i NFSku je naprosto jedno, jaky souborovy system je pod nim.

Tak uplne jedno to neni. Minimalne v pripade NFS, musi(musel) mit kazdy filesystem podporu pro NFS kernel server. S tim mel svyho casu velky problemy reiserfs, a HR na to kaslal a tvrdil, ze kernel nfsd je stejne blbost. Jestli jeste mate nekde hodne staryho Debiana tak schvalne zkuste udelat reiserfs v /mnt/neco1. Do nej namontujte /mnt/neco1/neco2 taky s reiserem a pak vyexportujte /mnt/neco1 pres NFS.
Alespon u me to funguje tak, ze pres NFS nevidim obsah adresare /mnt/neco1/neco2.

To nejde ani pres EXT2/3 - se exportuje jen jeden filesystem a pres mountpointy nfsd nepreleze bohuzel. Pokud mate nekdo info jak to obejit, at da vedet :)

Muzu jen potvrdit, ze na XFS to taky nejde. Lamal jsem si s tim hlavu nakej ten rok zpatky :o)

To jít nemůže, protože NFS se chová jako mount --bind přes síť. Jediná možnost je exportovat oba filesystémy samostatně.

Tato informace je z oficiálního webu, nevymyslel jsem si ji a minimálně reiserfs měl dřívě ve spojení s NFS problémy, takže ta podpora ze strany FS musí být.

NFS vám nikdo nebere. Samba ale nepotřebuje podporu ze strany FS a klidně můžete exportovat třeba FUSE.

Ok.. vyškrtnu.

Kdysi, 2000?, jsem měl problém se Sambou coby PDC, její funkčností a rozšířenými atributy. Nějaká kombinace kernelu a ext2/3 to nepodporovala. Nasazoval jsem kvůli tomu v té době čerstvý port XFS z oss.sgi.com.

hm, to znulování souborů otevřených pro zápis na xfs je celkem zásadní problém pro domácí použití na pc bez ups. používám jak xfs, jfs a reiserfs, ale pro jakýkoliv další oddíly asi začnu používat ext3/4. je to ověřený, žádný problémy, rozdíly mezi fs téměř nulový (pro non-critical systémy) a ta rozmanitost světa free softweru taky znamená jen svobodu pro tvůrce, uživatel má držet hubu :( .-..

Konkrétně je to např. zde: http://oss.sgi.com/projects/xfs/faq.html#nulls Ovšem mezi tím se z toho stala pěkná městská legenda, tak se to zopakuje u každého textu o XFS…

Nejak mi unika, k cemu mit zurnalovaci FS, ktery ma problemy prezit pad systemu (a neumi se korektne obnovit)?

Ale on se obnovi, tj. nebude v nekonzistetnim stavu a nebude treba provadet zdlouhavou kontrolu. Pouze prijdete o data ;-)

K cemu jsou mi data, hlavne ze je FS konzistentni ;)

Lepší mít systém v pořádku a nějaká data než mrtvý systém a žádná data.

Bohužel na tom při výpadcích není tak dobře jako zmíněné tři souborové systém,...

Opraveno

Zda se mi, ze v posledni dobou se roztrhl pytel s vybery,testy FS. Pro nas obycejne smrtelniky se mi zda ten ext3, potazmo nastupujici ext4 dostacujici. Tim nechci odstrkovat ostatni FS, jejich vyhody a nedostatky.

Ba ne, pratele, onehda jsem vyzkousel SpadFS a rychlost mi opravdu ucarovala - Ext3 to strcilo hrave do kapsy. (Pravda, jednalo se pouze o jeden temer synteticky problem - vytvoreni nekolika set tisic malych souboru. Jine pokusy jsem neprovadel, takze je to mozna v jinych ohledech jinak. Nicmene oproti Ext3 jsem videl 20 nasobne zrychleni!)

Libi se mi jednoduchost a primocarost, s jakou je SpadFS naprogramovan - zda se mi, ze to funguje prave proto, ze to neni nikterak slozite, ale naopak genialne jednoduche.

Chystam se na reinstal systemu a tesim se, jak si tam dam SpadFS - mozna je mi ten system take sympaticky, protoze je naprogramovany nasim starym znamym BLEKem.

Konec agitace ;-)

Jj, crash counts místo žurnálu a extendible hashing místo stromů jsou tak geniálně jednoduché věci, že to mohl vymyslet jen psychopat :)

Negative. Rozdiel len napriklad v takom mazani velkeho suboru na ext3 a xfs je niekolkonasobny.

> Stejně jako reiserfs a ext3/4 žurnáluje pouze metadata.

Mam takovy matny dojem, ze ext3 podporuje option zda zurnalovat jen metadata nebo vsechna data. Nebo si to pamatuju spatne (uz jsem s tim dlouho nedelal)...?

obavam se, ze ext3 (a zrejme i ext4) zurnaluje vse

Obáváte se špatně. Ext3 může žurnálovat data (jurnal_data) nebo jen metadata (ordered), nebo ještě rychlejší žurnál metadat s trochou rizika (writeback). Ten poslední způsob je používaný (a jediný možný), u reiser, xfs, jfs. Ext3 je obvykle nastaveno na ordered. Pro ext4 se toho v tomto směru moc nezměnilo.

Reiser4 už žurnáluje i data, má na to nějakou spešl technologii "wandering logs".

http://www.linuxtopia.org/HowToGuides/ext3JournalingFilesystem.html

Jo, takze si to pamatuju dobre a autor clanku keca nesmysly (!)

mate recht...
Dneska uz to tak chodi, autor clanku projede par webu, ktere vypadnout z googlu, protahne je google
translatorem, nejvetsi bludy trochu upravy, ted prijde na radu autorska tvorba a tim je vymysleni nadpisu ""Odstrcene souborove systemy" a par vet do zacatku ... = root.cz

Informacia, ze prevenciou nulovania suborov pri pade XFS moze byt RAID pole je blbost.
RAID neochrani pred [z jeho pohladu] umyselnym prepisanim dat...
Jedine ta UPS ma vyznam. Ale aj na poli aj na servri.

No jak se to vezme, pokud mam skutecny RAID s rekneme 1-2GB cache a baterku na cache, tak je velka sance, ze ze zapis provedl, protoze sel do cache radice, coz je dnes vetsinou ECC DDR2 ... takze smusl to ma.

Pouzivam na vsech systemech (desktopech i serverech) vyhradne XFS uz minimalne 4 roky.

Co je na tom zajímavého? :-)

A pijes 3 litry kafe denne, na noc beres diazepam na den neurol a i ty vlasy co ti zbyly jsou sede barvy :)

pred par lety jsem testoval JFS na vypadky a mel s tim tezke problemy, po kazdem vytazeni el. se musel rucne opravit a katastrofa byla i to, ze jsem udelel textak zapsal do nej data, pak jsem do nej dalsi pridal, pockal 10 min a vypojil el.

Po nabehnuti FS nenamountoval a po porave jsem v tom souboru mel stara data .... takze jsem jej zavrhl, protoze kdyz se OS flaka tak si myslim, ze i 2 sec je dlouha doba, natoz 10 min aby zapsal par kilo.

Jak mam tomuto FS verit, ze pri masivnim zapisu a vypadku tam jeste budu mit neco, spise budu mit kupu nekonzistentnich souboru.

Mozna je na to parametr, ktery neni v default volbe, ale stejne me to zaskocilo, jinak byl ze vsech normalnich FS nejrychlejsi .... az nato, ze jsem mu neduveroval.

Na druhou stranu. Co ma proud co vypadavat? Od toho jsou UPSky a Diesel-generatory. Myslim, ze resit to na urovni FS, je zbytecny overhead. Musi to byt samozrejme takto dokumentovano (Neco jako. Proud vam vypadnout nesmi! Tecka! :-) ) a pak je to v poradku.

Ehm, seda je teorie... Chtel bych videt nekoho, jak spoleha na to, ze proud proste nevypadne.

Treba XFS a jeho clusterova varianta CXFS

Stejne je system po vypadky elektriny na draka. Mate treba konzistentni filesystem, obsahujici zcela nekonzistentni data aplikaci. Proud vypadnout nesmi. Tecka! :-)

Takze klidne muzu presunout dulezita firemni data na velky RAMdisk a citit se v pohode, protoze proud prece nevypadava, ze...

Klidne, mate prece UPS a zalohujete kazdy den.

Zalohuje prece automat, o to se neni treba starat, akorat to zarve, kdyz je treba vlozit dalsi paletu s paskama. (Nekolik dni v predstihu samozrejme)

Takze je o to se treba starat :-) A neni taky od veci mit postupy na pravidelnou kontrolu jestli z te pasky to jde opravdu obnovit :-)

To dela taky automat :-) plus uzivatele, kteri si s oblibou mazou data, ktera vzapeti potrebuji.

Ano vsechno dela automat a pak kdyz neco potrebuje clovek tak to nefunguje. Viz par poslednich vypadku elektriny v hosting housech pri kterych selhali generatory :-)

Amateri....

Ve slusne firme nevypadava. Tady, kdyby vypadl, tak je to katastrofa, protoze tu bezi neprerusitelne provozy. Takze UPSky jak barak a pri vypadku delsim nez 5 minut naskakuje diesel generator. Ja mam treba generator v projektu sveho prave rekonstruovaneho domu.

Paranoia?

Ne, ale dum zcela zavisly na pocitacich. Rizeni kotle, kolektoru, kamerovy system, alarm, ....

Asi jo :-)

No ale to tě stejně 100% nechrání před bleskem, požárem nebo nějakou jinou katastrofou. Na to bys potřeboval geografický cluster.

Pasky se kazdy tyden odvazeji na druhy konec republiky.

A mimochodem, velke paralelni filesystemy maji cache v radu GB, takze to je vicemene RAMDisk :-)

Nie je to RAMdik :) Ked mam pole s kapacitou 50 TB, ktore ma cache 256 GB, tak len velmi male percento dat sa do nej zmesti. Druha vec su optimalizacie, aby tych 256 GB dat v cache bolo naozaj tych, ktore sa pouzivaju najviac.

>Co ma proud co vypadavat? Od toho jsou UPSky
>a Diesel-generatory. Myslim, ze resit to na
>urovni FS, je zbytecny overhead.

Obcas nepomuze ani UPS a dieselgenerator. Napriklad za chodu vypadne napajeci konektor disku nebo zakladni desky (zazil jsem oboji), uzivatel vykopne kabel z konektoru ve zdroji (proc sakra nemaji tyhle zasuvky nejakou formu zamku?), selze ventilator ve zdroji (naprilkad do nej uzivatelka zastrci krokosvorku od zemniciho kabliku filtru k monitoru tak, ze zablokuje lopatky ventilatoru) a ten se sam z duvodu prehrati vypne a tak dale. A to ani nemluvim o padech zpusobenych softwarem a operacnim systemem ...

Dulezita data nebyvaji na strojich, ze kterych muze uzivatelka vykopnout kabel (pokud neni schopna prokopnout zamceny rack). Slusny server ma navic zdroje 2-3.

Uha, tak to chce nastavit ve fstab aby OS po restartu udelal jsf.fsck na oddil. Protoze pripojit nekonzistentni jsf muze mit katastrofalni nasledky. Ovsem pokud se to nastavi, system to udela automaticky (mluvim o linuxu). Pouzivam JFS na notebooku a jsem plne spokojeny.

Jak je to s podporou JFS v openSUSE? Ve verzi 10.0 podporu JFS vypustili a lidem bylo doporuceno prejit na jiny FS. Ve verzi 10.1 take nebyla. Uz se to zmenilo? Pokud ne, tak by stalo za to to v clanku zminit, protoze vypusteni podpory ve me zanechalo dojem, ze z hlediska udrzby kodu nejsou XFS a JFS ve stejne kategorii.

Nemáte pravdu. Podpora JFS byla v 10.0 i 10.1 a je samozřejmě i v novějších verzích.

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).

-Yenya, http://www.fi.muni.cz/~kas/blog/

njn, aneb najdi 10 rozdilu

http://en.wikipedia.org/wiki/JFS_(file_system)
http://en.wikipedia.org/wiki/Xfs

http://www.root.cz/clanky/xfs-a-jfs-odstrcene-souborove-systemy/

Ří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.

no ja dost pochybuju ze by tohle oracle nebo db2 pouzivala.

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.

Kdesi som cital, ze ak je XFS ako rootFS, tak system nemusi spolahlivo bootnut. Neveril som tomu a na novej masine sm spravil primarnu particiu XFS. Nabootovat som z nej nedokazal. Odvtedy pouzivam xfs len na velke particie na ukladanie dat. Preco to nebootuje aj ked je to vseobecne znamy problem, sa mi nepodarilo zistit ...

Ja mam XFS na NB jako rootfs, akorat mam jeste ext3 /boot

jinak do XFS nesmite davat zavadec, pouze do MBR, XFS totiz nelaokuje misto, jako jine FS pro bootvani za part, tedy dosjde k poskozeni FS, je to popsanou u XFS

tak toto asi nie. Ja pouzivam na roote XFS na 3 pc (2 stolne a jeden notas - tuto je to dokonca usb disk) a absolutne nemam s grubom (0.97) ziadny problem.