Sziasztok!
Tudom már megint egy újabb ilyen idióta kérdező:)
A következő lenne a kérdésem:
Adott egy rendszerünk amin jelenleg minden ext3 alatt van. Pár hónapja elburult fsck közben az egyik partíció. Elég kényes programrendszer lett oda majdnem, lényegében majdnem teljesen.
A mostani karbantartás alatt felvetődött, hogy lecseréljük alatta a fájlrendszert.
A fájlrendszeren a következő szempontok alapján kéne döntenem:
- Sok 53 byte-os állomány, amik néha ha feltorlódnak órák alatt akár milliós nagyságrendre is nőhetnek és sajnos ez egy mappában.
- Rendszeresen jönnek létre 300->4,5G állományok is (naponta két alkalommal)
- A rajta létrejövő adatokat sajnos elég gyakorta (percenként) nyálazza át a find (ez főképp akkor gond, ha az apró fájlok feltorlódnak)
- Elég jelentős (cc 300) kliens használja majdnem mindig egyidejűleg
- Van egy mappaszerkezet amiben 53 byte -> 120-150k méretig vannak átlagosan fájlok, 90 napig. Ezek száma 150ezertől akár 500ezer is lehet. (Nem pontosan egy mappában, hanem 47-ben szétosztva, de nem egyenletesen) Ezen szerkezetnek a feldolgozása elég erőteljes IO wait létrehozását szokta jelenteni.
Ami még probléma, hogy mindenképp kernelfordítás lesz a fájlrendszer csere előtt, mivel a jelenleg futó kernel csak ext3 támogatást tartalmaz. (Nem, nem tudom letölteni hozzá a megfelelő modulokat, még mielőtt megkérdezné valaki.)
A rendszer folyamatosan működik, esetleg rendkívüli okok miatt áll le évközben. Mostantól január 5.-éig tudok változtatni, amennyiben akarok.
Amire gondoltam eddig, az az xfs és a reiserfs. Csak nem tudok határozni. Mindegyikre van pro és kontra. Azonban mivel kritikus helyen működik, nem szeretném ha arra kelnék éjszaka közepén, hogy elborult a rendszer. (Hideg tartalék rendszer van, rendszeresen mentve is van szalagra)
A válaszokat előre is köszönöm!
Üdv.: Árpád
- 7034 megtekintés
Hozzászólások
A választott filerendszertől függetlenül, ha nyugodtan akarsz aludni, akkor készítesz rendszeres backup-ot.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ez a reiser4 ez most már "halálfia"?
http://www.linuxvilag.hu/content/files/cikk/26/cikk_26_31_33.pdf
http://www.linuxvilag.hu/content/files/cikk/32/cikk_32_30_33.pdf
vagy megvárni btrfs-t - addig meg mindegy?
- A hozzászóláshoz be kell jelentkezni
Szerintem igen. Bár én a Reiser4 körüli dolgokat az utóbbi másfél évben nem követem, szóval nem nagyon tudom mi van vele. Tippelem, hogy vége. A btrfs-re még egy kicsit várni kell.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Szerintem ne filerendszereken gondolkozz, hanem gondolt át a struktúrát mégegyszer.
Alapvető: a gyakori, sok kis filet tedd másik partícióra, mint naponta létrejövő nagyokat! tunefs-el tunningold. Mivel oda mountolhatod, ahová nem szégyelled, ezért a programnak maradhatnak uott a könyvtárai, nem kell átírni. A sok kis file esetében én pl kikapcsolnám az accessed flag-et is, sokat gyorsít (man fstab), de persze csak akkor, ha nem zavarja az archíválást.
Imho hiába állsz át másik fs-re, mindre igaz az, hogy nem képes azonos paraméterekkel sok kis és nagy fileokat is hatékonyan kezelni.
- A hozzászóláshoz be kell jelentkezni
tavaszi nagy kutakodásom eredménye az volt, hogy az xfs-t az apró sz@rokra lassabbnak vélte a többség.
- A hozzászóláshoz be kell jelentkezni
A Reisert nem ismerem/használtam, de az XFS-t felejtsd el, ha a gép alatt nincsen egy atombiztos UPS. Azzal ti. még nagyobbat szívhatsz, mint Ext3-mal.
A személyes javaslatom amúgy az, hogyha megoldható a futtatott szoftverektől, akkor tegyél föl Solaris 10-et és használj ZFS-t.
--
"Only an expert can deal with the problem"
- A hozzászóláshoz be kell jelentkezni
+1, de csak akkor, ha veszel hozzá Hitachi storage-ot is :-D
- A hozzászóláshoz be kell jelentkezni
van benchmark is. apróbb fájloknál gyorsabb, lásd notail
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Játsszuk el akkor Reiserrel és ZFS-sel is azt, hogy kirántjuk alóla az áramot! :))
--
"Only an expert can deal with the problem"
- A hozzászóláshoz be kell jelentkezni
Előbbivel eljátszottam jónéhányszor az elmúlt 10 év során (pl. laptop lemerült és magában leállt). Egyszer nem volt vele problémám. Mondjuk én Reiser-t desktop célra használok. Van egy darab "szerveremen" tárterületként ReiserFS, de azzal sem volt az elmúlt öt évben probléma. Szerveren jellemzően ext3-at használok. De azzal sem volt eddig - lekopogom - semmi problémám. :) Jó szünetmentes kérdése az egész.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Viszont, ha normális IO terhelés van a gépen, akkor áramkimaradáskor ReiserFS jó eséllyel megy a lecsóba...
"Jó szünetmentes kérdése az egész. "
És redundáns tápé.
- A hozzászóláshoz be kell jelentkezni
"Viszont, ha normális IO terhelés van a gépen, akkor áramkimaradáskor ReiserFS jó eséllyel megy a lecsóba..."
Próbáltad? Vagy miből gondolod?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
(Láttam ilyet. Lehet csak véletlen volt. :D )
- A hozzászóláshoz be kell jelentkezni
Az utóbbi évben kétszer is láttam reiseren adatvesztést áramszünet miatt.
Ext3-ak rendre túlélték.
- A hozzászóláshoz be kell jelentkezni
Jézusom milyen helyeken jársz te. Két áramszünetet szünetmentes nélkül egy év alatt adatsérüléssel? :D
Én amondó vagyok, hogy nem a filerendszerek áramszünettűrő képességére kell játszani, hanem a normális üzemeltetésre.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
sok-sok helyen, és ebből 2 alkalom volt ilyen.
Egyébként a többszázmilliós géptermekben sem tudod 100% kivédeni ezt a hibát.
Kb 3 hete egy elég nagy gépteremben basztak el valamit a villanyszerelők, és kb 2-300 szerver alól ment ki az áram. :)
- A hozzászóláshoz be kell jelentkezni
"de az XFS-t felejtsd el, ha a gép alatt nincsen egy atombiztos UPS"
March-2007 Fixed the notorious "NULL files" problem
after a crash. The fix improves the syncronisation
between updates of the file size and writes that extend a file.
___
info
- A hozzászóláshoz be kell jelentkezni
Reiser-rel nagyobb adatvesztest csinalhatsz, mint ext3-mal barmikor szvsz. XFS is meg biztosabb nala, de meg az sem egy eletbiztositas - boven nem :). Inkabb backupolj rendszeresen, mert igazabol linux ala ext3 a legmegbizhatobb filerendszer, es mint latod ez is tud adatvesztest produkalni.
-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)
- A hozzászóláshoz be kell jelentkezni
+1, és szerintem RAID-10
- A hozzászóláshoz be kell jelentkezni
Ha van sok pénzetek (és RedHat, v. Suse Enterprise-t futtattok) vehettek VxFS-t (Veritas File System.).
Szerintem az legstabilabb FS, és a teljesítménye is igen jó.
- A hozzászóláshoz be kell jelentkezni
Nemrég fel akartam tenni a hup-on egy hasonló kérdést,
ki milyen fájlrendszert használ X terra felett és milyen célra.. mert..
.. bár egy tucat fájlrendszer van linux alá, nincs egy megbízható
storage-ra való fájlrendszer sem (nem kereskedelmi), mindegyik fostalicska.
Vagy ez van benne szarul megvalósítva (quota, összeomlás utáni ellenőrzés (ext3)),
vagy más.. vagy egyszerűen gáz van vele..
A gáz van vele-hoz egy adalék.. ha xfs-t akarsz sambával és nagy terhelés alatt használni,
akkor felejsd el.. ebben az évben csak kétszer szállt el két különböző rendszerünk az xfs miatt.
Érdekes olvasni való: http://oss.sgi.com/projects/xfs/faq.html#dir2
Maradj a backup-nál, meg az ext3-nál.. azt is lehet optimalizálni.
- A hozzászóláshoz be kell jelentkezni
Huh...
A backupunk az oldschool linux eszközöket használja, és az időadatokra szükség van a mentéshez. :(
Azt én is aláírom, hogy az ext3 az eddigi legjobb fs amit használtam. Csak lenne egy normális fsck hozzá....... A múltkor láttam mire képes az ups, mikor sikeresen elnyiszálták az ipari parkunk betápját. Kb. 1 órát bírta mielőtt lemerült volna, bár ez esetben ott voltunk és lekapcsoltunk mindent időben.
A struktúrán már gondolkodtam, és látom is, hogy nem így kellett volna, azonban a rendszert író "programozók" így tervezték meg... Osztrák tervezés, magyar szívás :D
Jelenleg redhat el 4 fut, de pár hónapja járt le a supportunk, azonban a jelenleg nem tudtuk kierőszakolni a hosszabbítást :( ráfogták a válságra és oldjuk meget kaptunk válaszként. Így meg nem egyszerű.
A Solaris sajnos számomra elérhetetlen. Anno Sun-tól kértem egy tesztmédiát, azonban még egy nyamvadt ip-t sem tudtam állítani rajta. És nem tudom a termelésirányítási rendszerünk fut-e Solarison. AIX-es binárisai vannak ennyit tudok.
Bocsánat ha nem magyarul fogalmaztam, de az életerőm erősen konvergál a nullához a mai nap után.
- A hozzászóláshoz be kell jelentkezni
A Solarishoz csak annyit, hogy nem kell tesztmédia, letölthető. De ha tényle nem értesz hozzá, akkor felejtős. Mondjuk ha vannak erős linuxos alapjaid, akkor nem vészes beletanulni, tehát teljesen ne húzd ki ezt a lehetőséget se.
--
"Only an expert can deal with the problem"
- A hozzászóláshoz be kell jelentkezni
Kb. 1 órát bírta mielőtt lemerült volna, bár ez esetben ott voltunk és lekapcsoltunk mindent időben.
Automatikus shutdown-t miért nem lövitek be apcupsd-vel vagy nut-tal?
---
Linux is bad juju.
- A hozzászóláshoz be kell jelentkezni
Access time -ra? Az minden megnyitaskor valtozik.
mtime csak akkor ha modositod, mi fenenek kene todnod menteskor, hogy mikor fertek hozza utoljara ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
"- Sok 53 byte-os állomány, amik néha ha feltorlódnak órák alatt akár milliós nagyságrendre is nőhetnek és sajnos ez egy mappában."
Meg sem merem gondolni, mik ezek (telemetria, gps ...), de valszeg jobb is ha nem tudom :)
minden esetre ezt miért nem lehet *SQL-be tolni, vagy memcached-be? Esetleg így: http://memcachefs.sourceforge.net/
Ha nem ez akkor reiserfs, nem hinném, hogy ezt más elviselné.
"- Rendszeresen jönnek létre 300->4,5G állományok is (naponta két alkalommal)"
LVM köteten XFS file rendszer.
"- A rajta létrejövő adatokat sajnos elég gyakorta (percenként) nyálazza át a find (ez főképp akkor gond, ha az apró fájlok feltorlódnak)"
Hát az ellen nem véd, ezen csak a nyers erő segít, SAS SCSI RAID 1+0, RAID 5+0 és valami komoly RAID controller(ek). Mellesleg, ha a fileok átlag mérete 10kB és 500ezren vannak, akkor az 4,7GB az ilyen programozó - elnézést mindenkitől - egy állat!
Még annyit, hogy ennyi file legenerálása aztán find-al végignyalni önmagában agyrém, ezen a rendszeren (alkalmazáson) feltétlen optimalizálni kellene!!!
----
Nyicc-egy-csört?
Esetleg nézd meg itt: http://kayapo.extra.hu/
- A hozzászóláshoz be kell jelentkezni
"Meg sem merem gondolni, mik ezek (telemetria, gps ...), de valszeg jobb is ha nem tudom :)"
- a termelésben résztvevő gépek ún. kész üzenetei munkafázisonként -.- mi sem értjük miért van így, mi sem értjük ha ott alatta az oracle akkor miért kell a moduloknak fájlokkal kommunikálni, de ez van 100 millát nem dobhatunk ki az ablakon :(
- jelenleg egy hp raid vezérlővel fut a rendszer, raid 5-ben
- mikor pár hónapja összeborult a fájlrendszer, előtte feltolt a rendszer 4,3 milla fájlt egy mappába. Csak mert egy nyamvadék cron szkript leállt, majd lett 40 findom, meg 80-as terhelésem... akkor átírtam a szkripteket amiket a termelésirányításhoz írtak, és azt hittem meghalok:
- létrehoz egy lock fájlt, ismert helyen, ismert tartalommal
- megkeresi find-al
- ha megvan letörli
Na erre szerintem kitalálták az if-et, a testet, és az rm-et :) és hogy ne menjen olyan gyorsan még egy sleep is lett benne. Erre a fejlesztők leugatták a fejem, hogy hogy mertem belenyúlni. (persze mikor a legutolsó hibajegyet leadtam nekik, pontosan leírva mi a gond, hogy lehet megoldani, kicsit máshogy de az én elvemmel oldották meg :D)
Szóval marad úgy. Ezen változtatni nem tudok. Próbáltunk már, de nem tudtuk kierőszakolni, hogy legyen mindez adatbázisszinten. :(
- A hozzászóláshoz be kell jelentkezni
Ki volt az a tudatlan, aki RAID5-ös tömbre rakott egy ilyen rendszert, ami ennyit írkál? Ökölszabályként mondják ugye, hogyha az I/O 20%-ánál több az írásművelet, akkor a RAID5 felejtős. Lehet, hogy nem is másik filerendszer kellene először neked, hanem normálisan felkonfigurált lemeztömb? :)
--
"Only an expert can deal with the problem"
- A hozzászóláshoz be kell jelentkezni
+1, RAID5-öt csak akkor, ha ritka írás és gyakori olvasás a jellemző.
Szerintem mondd meg nyugodtan a főnöknek, hogy nem tudsz mit tenni, hiába varázsolsz filerendszerekkel, a szoftverrel van az alapvető baj. Azért a külön partíciót mindenképp megjátszanám a helyedben.
- A hozzászóláshoz be kell jelentkezni
Ez esetben mi a megfelelő raid level?
- A hozzászóláshoz be kell jelentkezni
Nem tartozik a temahoz, de szerintem ketfele rendszer van:
1) olyan kicsi a load, hogy teljesen mindegy, hogyan csinalod, de ha megnyugtad, alkalmazhatod az 'okolszabalyokat'.
2) olyan nagy a load, hogy feldughatod a seggedbe az okolszabalyaidat, es elkezdhetsz gondolkozni.
Pl. ha a bbwc elbirja a diszkekkel az irast, akkor teljesen mindegy, hogy az i/o 20%-a, 3%-a vagy 95%-a write.
- A hozzászóláshoz be kell jelentkezni
> nem tudtuk kierőszakolni, hogy legyen mindez adatbázisszinten
Fájlrendszerként elérhető adatbázis javítana a helyzeten?
http://apps.sourceforge.net/mediawiki/fuse/index.php?title=DatabaseFile…
- A hozzászóláshoz be kell jelentkezni
Pedig nem rossz az az ext3, kulonosen ha bekapcsolod a full journaling-et. Egyebkent a ZFS-nek +1, abban van egy csomo jo integritas-vedelmi ficsor.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
ext4-el mi is a helyzet?
- A hozzászóláshoz be kell jelentkezni
Látjátok milyen jó a BSD-seknek? Ti itt álltok millió plusz egy fájlrendszerrel, és azt sem tudjátok melyik lenne jó az adott feladatra.
A BSD-kben csak UFS van, így a kérdés fel sem merül. >;-)
- A hozzászóláshoz be kell jelentkezni
zfs?
- A hozzászóláshoz be kell jelentkezni
A FreeBSD-ben nem épp életbiztosítás egyelőre. Ennyi erővel ext2-őt is használhatsz. :)
- A hozzászóláshoz be kell jelentkezni
debian unstable-ben van UFS, már csak azt nem tudom mennyire unstable, én testing-et használok /pill. kíváncsi lennék, hogy csak és kizárólag sid-del UFS partíciókat mennyire stabilan tud kezelni ...
- A hozzászóláshoz be kell jelentkezni
RO
___
info
- A hozzászóláshoz be kell jelentkezni
nálam etch-ben a 2.6.26 debianos kernelforrás doksija szerint ezek az UFS típusok R/W-k: 44bsd, 5xbsd, ufs2, sun, sunx86. tehát doksi szerint a BSD-s UFS-re tud írni a testing, gondolom unstable-ben nem változtatták át RO-ra ...
- A hozzászóláshoz be kell jelentkezni
Problémám hasonló, "file rendszert, de milyet?"
Van egy ssd-s acer laptopom. Milyen filerendszert tegyek rá, hogy ne vágja haza idővel(de legalábbis belátható időn belül) az ssd-t?
- A hozzászóláshoz be kell jelentkezni
Hmm...
Szóval én ezt csinálnám:
1. legalább 3, esetleg 4-6 serverre drbd-vel elosztanám a klienseket
2. egy-két további serverre (szintén drbd) bíznám a fileok létrehozatalát.
3. file rendszer: ext4, valószínűleg
a drbd köteteket, mindenképpen RAID felett alakítanám ki és persze naponta többször mentenék (bacula, amanda, rsync akármivel)
----
概略情報
- A hozzászóláshoz be kell jelentkezni