Názory k článku XFS a JFS: Odstrčené souborové systémy?
-
GEDIK (neregistrovaný)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 ;-) -
FLEK. (neregistrovaný)>>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. -
Ivan (neregistrovaný)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. -
machrostroj (neregistrovaný)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 :( .-..
-
Nekde jsem cetl, ze se od toho zkracovani na nulu u novejsich verzi ustoupilo. Puvodne to bylo myslene tak, ze soubor u ktereho neni jiste ze obsahuje spravna data nema obsahovat zadna data a nezakryvat chybu. Admin potom udela obnovu ze zalohy a jede se dal. Kdyz se skryje, ze data jsou poskozena, muze se na to prijit az v dobe, kdy jsou vsechny zalohy odrotovane. -
Filip Jirsák (neregistrovaný)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…
-
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 ;-)
-
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. -
capslock (neregistrovaný)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 -
Izak (neregistrovaný)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. -
Kvakor (neregistrovaný)>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 ... -
No to se divim.
Ja nemam na AIXech s JFS/JFS2 naprosto zadny problem a vzhledem k tomu, ze spravuji i nekolik starsich IBM serveru u zakaznika, ktery nema prachy na poradne zalozni zdroje, tak se mi jeste nestalo (9 let), ze by byl s timto FS jakykoliv problem, jakmile AIX videl fyzicke disky ve VolemuGroup, tak jsem ty FS vzdy bez problemu namountoval a jelo to dal...
Vlastne jednou si vzpominam na problem, ale check FS to opravil behem chvilky a bez problemu...
O. -
C3 (neregistrovaný)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.
-
Yenya (neregistrovaný)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/ -
Karel a Karel (neregistrovaný)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/ -
FOK (neregistrovaný)
Řídké soubory
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.
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. -
Field (neregistrovaný)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. -
Dodo (neregistrovaný)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 ...
-
anonymníXFS na rootfs bootuje v pohode uz od prvych verzii implementacie v linuxe. Mazanie v nom je naozaj citelne pomalsie ako v inych FS - niekedy sa podari vytvorit a zapisat velky pocet malych suborov rychlejsie ako ich vymazat :( DObre na tom je ze ich vytvorenie je fakt rychle. Pouzival som XFS na raid0 systeme a az tam sa ukazaqla jeho sila, pri pouzivani na desktope - najskor linux teraz irix az tak moc nevinika. Nikdy sa mi este nestalo ze by po pade systemu zostali na XFS prazdne subory takze ku tejto veci sa neviem vyjadrit. Pamatam si len ze vo verzii jadra ~2.4.26 alebo tak nejak bol problem nabootovat po tom ako bolo xfs nekorektne odpojene. Casom sa to zlepsilo.
Na irixe je to nativny FS tak tazko porovnavat z niecim inym ale po pol roku realneho kazdodenneho puouzivania to vypada ze funguje na 100% -> a zazil som uz aj vypadok stavy... -
anonymníXFS na rootfs bootuje v pohode uz od prvych verzii implementacie v linuxe. Mazanie v nom je naozaj citelne pomalsie ako v inych FS - niekedy sa podari vytvorit a zapisat velky pocet malych suborov rychlejsie ako ich vymazat :( DObre na tom je ze ich vytvorenie je fakt rychle. Pouzival som XFS na raid0 systeme a az tam sa ukazala jeho sila, pri pouzivani na desktope - najskor linux teraz irix az tak moc nevinika. Nikdy sa mi este nestalo ze by po pade systemu zostali na XFS prazdne subory takze ku tejto veci sa neviem vyjadrit. Pamatam si len ze vo verzii jadra ~2.4.26 alebo tak nejak bol problem nabootovat po tom ako bolo xfs nekorektne odpojene. Musel som bootnut rescue system a spustit xfs_check stade. Casom sa to zlepsilo (alebo mi inak padal komp) :)
Na irixe je to nativny FS tak tazko porovnavat z niecim inym ale po pol roku realneho kazdodenneho puouzivania to vypada ze funguje na 100% -> a zazil som uz aj vypadok stavy...
