Dotaz: Filesystem na serveri

[Karol]

Ahojte.
Chcem sa vas spytat aky filesystem by ste zvolili na server, ktory ma 3x 1.2 TB disky (nebudu v raide, ale pripajane samostane, kazdy do svojho adresara, cize ziadne LVM), budu obsahovat 50-300 MB fajle ktore bude publikovane cez apaca.

Bolo mi povedane, ze ext3 nie je na taketo nieco vhodne (rychlost, naroky na CPU). Mam vraj skusit JFS.

mate niekto nejake skusenosti s tymto? Nemozem si dovolit o tie data prist ani keby krompace z neba padali.
Je pouzitie JFS naozaj bezpecne? Cital som rozne topici o JFS, XFS aj ReiserFS ale:

XFS - velka cache. Pri pade ostavaju zapisovane fajle na "0".

ReiserFS - jeho prava sila je len na filesysteme s velkym mnozstvom malych suborov... .

JFS - zda sa, ze nema chyby. Ale vsetky nazory okolo neho boli od ludi co ho maju na laptope. Je rovnako dobry aj pre server???

Dakujem za pripadne odpovede.

Odpovědi

[Filip Jirsák]

Nebál bych se použít XFS. To zkrácení souboru na nulu při pádu už dávno nedělá, navíc předpokládám, že u serveru budete mít UPS a systém se tedy vždy řádně ukončí. Při pádu systému skončí v nekonzistentním stavu kterýkoli z vyjmenovaných souborových systémů, XFS to tím nulováním jenom přiznával uživateli.

[Karol]

Ok.

Spravil som si taky testik.

#mkfs.xfs /dev/sda10   (/home)

#mount /home; cd /home

#dd if=/dev/zero of=subor.dev bs=1024 count=8124000    (tento prikaz zacal vytvarat subor o velkosti cca 8 GB).

#ls -lah

........................ 2.2GB subor.dev

(pri 2.2vytvorenych gigabajtoch som pocitac pocas procesu "dd" natvrdo zresetoval).

Vysledok po restarte?

#ls -lah

........................... 0 subor.dev

 

Pri JFS a aj ext3 ostala zachovana posledna zapisana informacia, cize:

#ls -lah

........................... 2.2GB subor.dev

 

Spravil som v tomto svojom "improvizovanom" testiku v niecom chybu ja? Ukrivdil som XFS filesystemu?

Prosim zhodnodte kde som sa kopol...?   

Dakujem.

[linuxik]

Asi je vsechno v poradku XFS tak proste funguje, ale  resis zbytecnosti . Pokud mas server na UPS tak se nemas ceho bat a i kdyby se stalo ze server z nejakeho duvodu spadne, tak bude lepsi mit soubory nulove delky u kterych je hned jasne, ze je musis obnovit ze zalohy, pripadne znovu nahrat, nez nechat na disku soubory s  nekonzistetnim obsahem a zjistit to treba az za mesic.

ps. To ze ma na ext3 a jfs soubor 2.2GB jeste neznamena ze v nem skutecne je 2.2GB dat a uz vubec se nemuzes spolehnout na spravnost jeho obsahu. A stejne co by jsi s takovym souborem chtel po restartu delat?

 

[Filip Jirsák]

S jakou verzí jádra/XFS jste to zkoušel? A chybu jste udělal v tom, že jste porovnával jen velikost souborů, což je dost k ničemu. Protože na XFS jste dostal soubor zkrácený na nulu, zatímco na ostatních systémech jste dostal soubor s náhodně pomíchanými původními daty a náhodným šumem. Obojí je jako datový soubor k ničemu. Pokud potřebujete generátor náhodných čísel, použijte JFS nebo ext3 a nepoužívejte záložní zdroj (nebo si zařiďte pády systému jiným způsobem). Pokud chcete ukládat data, použijte XFS, JFS nebo ext2, používejte stabilní hardware a záložní zdroj, který dokáže systém varovat a ten se včas vypne.

[dino]

Pouzil som cistu distro Debiana lennyho. Neviem aka presne verzia jadra tam teraz je. 2.6.28? Mozno trepem.

Ale mate pravdu v tom, ze lepsie je mat subor s nulovou velkostou ako subor plny bludov.

Len sa trochu bojim -- co ak bude v zapise prave nejaky MySQL DB fajl. Nehrozi mi, ze sa mi "znuluje" ??? Keby sa mi posrala databaza, to by ma sralo este viac.

Ale prave som si precital:

http://www.root.cz/clanky/velky-test-osmi-linuxovych-souborovych-systemu/     a zrejme ostanem pri ext3 s moznostou neskorsieho prechodu na ext4.

Hmm?

[Filip Jirsák]

Pokud použijete stabilní hardware, stabilní jádro a záložní zdroj, nehrozí nic. Pokud budete mít nestabilní hardware, nestabilní jádro nebo nebudete mít vyřešen záložní zdroj, nenaběhne MySQL ani se souborem zkráceným na nulovou délku, ani se souborem, ve kterém bude spousta smetí -- nebo v horším případě naběhne, a že jsou data poškozená zjistíte až za měsíc. Jak pak budete mergovat nepoškozenou zálohu s tím, co zatím do databáze přibylo, to si nedovedu představit. Takže je to jedno -- bez UPS nebo na nestabilním systému to bude loterie vždy, v ostatních případech jsou všechny tři zmíněné souborové systémy dostatečně stabilní pro ostrý provoz.

[moz]

Z mé osobní zkušenosti: XFS rychlé, ale jak bylo již výše zmiňováno+na některých serverech se mi sám rozkládal(značkové servery -některé Fujitsu-Siemens a HP, ale asi mu nějak nesedly). Na nejnovějších jádrech jsem ho už nezkoušel. Naposled snad 2.6.18. Teď všude používám ext3 - rychlost ujde, zatím mě nezradila a co se týče třeba zmiňované databáze mysql, stalo se, že databázovému serveru padla i UPSka či spadlo jádro, datazáze pak šla opravit přímo v mysql rozhraní a žádné ztráty jsem nezaznamenal.

[pht]

IMHO ext3 s tím svým ordered módem by mohlo přežít i to nejhorší, trpí tím ale rychlost.

Jinak ad původní příspěvek: co se stane když mezi to první ls a tvrdý reset dáte sync?

[Karol]

Subor ostane zaplneny.

Lenze viete ako. Pri vypadku prudu sa ziadne sync nepodari nahodit.  Takze v tomto smere mi ide o princip. Ako XFS funguje.

Btw: Vcera som skusal XFS vs. EXT3 na 1.2 TB particii.

Mam z toho zmiesane pocity.

Skusal som ho zatazit napriklad tym, ze som mu dal vygenerovat 100 suborov o velkosti 30MB. Particia s XFS bola oproti EXT3 o 3 sekundy lepsia. ALE POZOR: Len pri vytvarani suborov. Pri ich prepisovani si naskok udrzala EXT3. 

Dalsia vec. Pri vytvarani tychto fajlov dosahovala rychlost XFS az 330MB/s. Naproti tomu kazdych cca 10 suborov sa o nieco spomalil (cca: 50-110MB/s - asi nejaka maskarada s cache) a po 3-4 suborov sa zasa nachvilku rozbehol na plnych 330MB/s.

Naproti tomu EXT3 sa v priemere drzal na 210MB/s, co je teda o dost pomalsie ako XFS ale zasa si tuto rychlost udrzal stabilne a vyssie zmienovane spomalenie nebolo tak caste ako v pripade XFS. Tak ci onak - XFS vyslo o 3sec lepsie, cize nieco natom bude, ze je rychlejsie... .

[pht]

Jenže sync je to jedno jediné co Vám spolehlivě data zapíše. Používají to databáze a všechny programy, které garantují že když ustřihnete napájení tak na disku bude to a to. Vše ostatní je jen iluze, jak již psal pan Jirsák přede mnou.

Když jste "měřil" ten fs, měl jste ext3 v ordered módu? Pokud ano, porovnáváte hrušky a jabka.

Taky byste měl uvažovat celkovou délku operace: pokud to trvalo 5 minut, k čemu Vám budou 3 sekundy navíc? Nemluvě o tom, že taková měření je vhodné několikrát opakovat a vypočíst statistiky -- průměr a rozptyl. Udělejte to celé s různými velikostmi souborů a vyneste do grafu a pak je možné něco o rychlosti fs říct.

[pht]

PS.

asi nejaka maskarada s cache

Zkuste si pohrát s dirty_writeback_centisecs a ostatními šoupátky.

[Karol]

Takto. Viete co mam k dispozicii. Viete naco to potrebujem.

Co mi odporucate?

Cele som to skratil a rozhodujem sa uz fakt len medzi XFS a EXT3.

 

 

[hysterix]

Fakt, ze jste byl ochoten venovat svuj cas na testy s havarii/vypadkem proudu znamena, ze pro vas je to realna moznost. Takze ext3. Jinak to zkracovani na nulu je dusledkem filozofie prace s diskem. Podobne chovani ma ext4. Jak uvadeji autori: pokud chcete rychly filesystem, proces se musi chovat s ohledem na vlastnosti filesystemu a ne jako kdyby bezel na DOSu 3.3

[Filip Jirsák]

Fakt, ze jste byl ochoten venovat svuj cas na testy s havarii/vypadkem proudu znamena, ze pro vas je to realna moznost. Takze ext3.

Jenže použití ext3 problém s výpadkem napájení nebo pádem systému neřeší, pouze před ním zavírá oči. Pokud nastavíte synchronizaci na disk na stejný interval, bude rozdíl jediný: XFS poškozený soubor přizná, ext3 ho nepřizná a "doufá", že se na to nepřijde.

Pokud byste chtěl souborový systém zabezpečený proti výpadku napájení, musela by se žurnálovat i data. Pokud by přišel požadavek na zápis, nejprve by se nová data zapsala do logu a udělal by se sync. Pak by se data zapsala na správné místo a záznam v logu by se potvrdil (poznamenalo by se, že byl aplikován). Teprve pak by se aplikaci vrátilo, že se data zapsala. Pak by bylo možné zajistit, že pokud kdykoliv dojde k výpadku, bude možné data na disku dostat buď do stavu po zápise, nebo před ním, ale nezůstanou v nějakém mezistavu. Pokud váš FS žurnál pro data nepoužívá, může vždy dojít k výpadku proudu v okamžiku, kdy z jednoho bajtu bylo zapsáno třeba 5 bitů a 3 ne -- a dostanete nekonzistentní data.

[pht]

musela by se žurnálovat i data

To je ale ten ordered mód u ext3.

[R]

Pri ext3 je defaultne nastaveny ordered mod. V tomto mode sa nikdy nemoze stat, ze v subore su neplatne data. Takze je mozne napr. pocas stahovania urobit tvrdy reset a potom kludne v stahovani pokracovat.

[Karol]

Aby som trosku uviedol veci na pravu mieru a zhrnul to.

---------------------------------------------------------------------------------------------------

Na server bude mat pristup par ludi, co budu uploadovat (max: 200-300 MB fajle) cez web rozhranie (cez nejaky PHP skript) a potom k tomu bude mat pristup dalsia skupina ludi, ktori budu tieto fajle cez web stahovat. Server je umiestneny v profesionalnom SERVERHousingu, kde by nemalo dojist k vypadku prudu. Aspon to tak deklaruju, ze maju k dispozicii generatory+UPSka, keby k niecomu doslo.

Cize v tomto smere tiez neocakavam problemy.

Preco uvazujem na zmenou FS?

Uz jednu generaciu servera s 2TB diskom som mal. A mal som ho naformatovany len na ext3. Stav po dvoch rokoch je taky, ze ext3 sa pomerne tazko pohybuje na particii velkej >1TB v ktorej je cca 8000 suborov v jednom adresari. Mam skripty, ktore kazdu noc prehliadaju disky, robia zoznam fajlov, porovnavaju s MySQL DB a podla toho ich bud zmazu alebo nechaju "zit".

S pribudajucim casom (a poctom suborov) mi tato nocna aktivita zoziera velke percento CPU, diskovej aktivity aj na niekolko HODIN. A vsetku vinu pripisujem prave EXT3jke.

Teraz mam server doma, mam ho moznost preinstalovat a znova pripravit na chod na dalsie 2 roky. Tuto moznost uz nebudem mat tak skoro, preto chcem vsetkej konfiguracii venovat patricnu pozornost. Tyka sa to aj vhodnemu vyberu FS. Za posledne 4 dni som prestudoval snad vsetko na internete co sa filesystemov tyka. A dospel som k nazoru, ze:

JFS - rychly, nenarocny ale s pribudajucim casom = velka fragmentacia = rapidne znizujuci sa vykon + nepritomnost defrag. nastroja pre linux = NO CHANCE.

ReiserFS - nepacia sa mi niektore topici o nom (a nasiel som ich dost), ze to ludom v urcitych situaciach nenavratne zhavarovalo + ten vyvoj je taky.... vseliaky, neisty. + nepouzivam vela malych suborov ale vela obrovsky suborov = NO CHANCE.

ext3 - nie prilis lichotiva skusenost s predoslej verzii mojho servera.

XFS - laka ma to. Ale nechcem skocit nevedomky do nejakej sracky! Fakt, ze subor pri zapise a pri vypadku ostava znulovany -- by mi nevadil. Dokonca to beriem mozno este aj ako vyhodu. Ja totiz nebudem vediet cez web-upload (vid info vyssie) nadviazat na ukonceny upload a pokracovat v nom. Jedina cesta pre mna bude zacat uploadovat novy subor. V tomto smere sa mi zda filozofia nuloveho fajlu odost lepsia.  Navyse XFS potrebujem dat len na particie s daatami. Nie so systemom. System hodim do EXT3.

Cize realne z toho co ste mi sem vsetcia napisali + co som sa mohol docitat mi vychadza, ze XFS by malo byt vhodne. A ak nie, tak dalsie v poradi EXT3.

Ostava len posledna otazka, ktora asi rozhodne o vsetkom a to: " Na ktorom FS sa bude bash-skriptu, spustaneho cez crona lepsie pohybovat medzi 8000 subormi? Na Ext3jke alebo na XFScku?"

Ext3 ma uz v tomto smere trochu sklamala (z predoslych skusenosti). Mozno by som ju mal skusit vytuningovat. (http://www.iprint.sk/ext3-tunning).

Problem je, ze nemam cas :-((      Dnes sa musim rozhodnut a zit s tym dalsie dva roky.  

Aaaaaaaaaaaa ako v tomto smere zavidim Windowsom. Tam je len jedna moznost = nie je co riesit. )

 

[pht]

cca 8000 suborov v jednom adresari

Možná by veškeré Vaše trápení vyřešilo rozdělení dat na několik adresářů. (Např. podle prvního jednoho nebo dvou písmen, jak to má squid.)

A nebo kdoví jak to řeší ten Váš skript, třeba by stačilo ho trochu algoritmicky upravit.

[dustin]

snip

Server je umiestneny v profesionalnom SERVERHousingu, kde by nemalo dojist k vypadku prudu. Aspon to tak deklaruju, ze maju k dispozicii generatory+UPSka, keby k niecomu doslo.

/snip

:) Zrovna včera v noci byl v jednom nejmenovaném velkém pražském serverhousingu výpadek natvrdo - generátory neutáhly všechny stroje, tak některé haly natvrdo odpojili.

[Filip Jirsák]

To už pak záleží na smlouvě. Ale vzhledem k tomu, jak často se něco takového děje, mne překvapuje, že serverhousingy nenabízejí nějakou standardní možnost havarijního odstavení (alespoň jsem to nezaznamenal). Pak jste na tom paradoxně lépe s malou UPS, která je schopná počítači včas říct, že dochází baterka a má se vypnout, než velký housing s akumulátorovnou a generátorem, který sice může dopředu vědět, že dojde k výpadku, ale nemá šanci servery korektně vypnout.

[dustin]

Přesně to jsem dnes providerovi navrhnul - obdoba apcupsd. Zatím neodpověděli :)

[Zdenek]

Zdravím Vás , nebál bych se XFS . XFS je rychlé , nemám problém s >2TB , pro našeho zákazníka jsem dodával server s 24*750GB disky SATA a server-NAS pole jede dodnes bez výpadku ( 2x opteron , XFS , RED-HAT ) .

Vše běželo na XFS v RAID5 , na tomto systému běží u nás celá nemocnice .... , těchto zařízení jsme dodávali celkem hodně.  JFS+REISER no asi ne , já se kloním k XFS.

[JF]

Mno a nestacilo by delat RSYNC kazdou noc na druhy disk treba u Vas doma?  Pak uz by Vam vypadek vubec vadit nemusel a RSYNC je celkem rychly, kdyz se spravne nastavi.

 

K tomu reiserfs. Oni jsou 2 verze reiserfs3 a reiserfs4. Nejisty vyvoj je jen u reiserfs4. Reiserfs3 je vyvinuta a spolehliva a je soucasti kernelu.

 

O ext3 jsem cetl dost nelichotive veci. Nekdy se stava, ze po tvrdem vypadku vyzaduje check a ten muze trvat i par hodin. Me se jeste nestalo, ze by check system nespravil, ale oprava 20GB trva na mem pocitaci hodinu.

[dino]

Rsync na 3x1.2 TeraBajtove disky?

Opravte ma ak sa mylim ale nie je rsync nieco ako file transport protocol??

[zdenek]

Rsync je celkem brutalne rychly , kdyz se pouziva na NFS to NFS pak dokaze vytizit linku na 100% , rsync se pouziva treba na kopii 1:1 vzdaleneho a mistniho systemu. Rsync je hodne pouzivany  na zalohy z produkcniho na backup server. Pouziva se i na prenosy vetsich souboru , ale hlavne pro synchronizaci , pouziva se i pro FTP prenosy.

[dino]

hmm. skoda len, ze nemam pre tolko dat dalsie miesto. :(

[Filip Jirsák]

rsync se snaží přenášet jenom změny, takže pokud se za den změní třeba 100 MB, přenese jen těch 100 MB + nějaká řídící data. Jenom je potřeba dát pozor na přepis souborů a mazání, pokud byste měl jen jednu zálohu -- když někdo omylem smaže soubor, v noci se smaže i ze zálohy a druhý den byste to zjistil, bude vám už záloha k ničemu. Low-endové terabajtové SATA disky jsou dneska za pár peněz, neměl by být takový problém připojit je třeba k domácí počítači a v noci zálohovat tam. Pokud tedy nemáte připojení k internetu s nějakým FUPem...

[Fuki]

Mam to chapat tak, ze ked databazovy subor ktory ma 1GB a pribudlo tam za den 10MB dat, tak rsync prekopiruje len tu 10MB zmenu (co sa mi zda scifi) alebo sa bude snazit prekopirovat cely 1GB subor lebo zistil ze je v nom zmena ?

[linuxik]

Skutecne to tak je,  rsync porovnava casti souboru a kopiruje pouze zmeny.

[Filip Jirsák]

K diskusi o FS doporučuji přečíst si dnešní Jaderné noviny -- Ext4 a ztráta dat. A poslední z citátů na začátku téhož článku taky stojí za přečtení.