A Linux sok területen a választásról szól. És most nem arra gondolok, hogy nem muszáj használni, lehet mást telepíteni. :)

Fájlrendszer fronton számos lehetőségünk van, amelyek között sokan személyes preferencia (ezt ismerem, ezt szeretem) alapján választanak. De vajon melyik fájlrendszer teljesít a legjobban MySQL alatt?

Nézzük:

suckit: mysql-linuxfs-rw.png

A fájlrendszerek a standard beállításaikkal lettek megformázva, a hardver és szoftverkörnyezet a korábbiakban említett (MySQL és PostgreSQL történelem cikkek).

Meglepő, hogy az ext3 ilyen fölényesen gyaláz mindenkit, a feltörekvő, új generációs FS-ek (btrfs, ext4) pedig mennyire rosszul teljesítenek...

A bejegyzés trackback címe:

http://suckit.blog.hu/api/trackback/id/tr911441336

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

AP! (törölt) 2009.10.12. 12:24:31

ha már fájlrendszerek, egy raw partíciós tesztet nem akarsz mellécsapni? :)

blackshepherd · http://suckit.blog.hu 2009.10.12. 12:26:54

@anyadnak_palankot: Nagyon jó ötlet, ez látod kimaradt. Sajnos a gép nem az enyém, így ezt pótolni már nem tudom. :(

lolcode · http://isten.aldja.szalaiannamari.at 2009.10.12. 12:55:41

ennel mar csak az a kinosabb ahogy az ext4 adatvesztos bug le lett kommunikalva

psr6 2009.10.12. 15:31:19

Én nem tudom miért, de mindig fáztam az ext.-ektől. Korábban reiserfs-el kerülgettem (3-as), most meg xfs-el. Ja, a vas a notebookom :). Azt hiszem, nem a filerendszer a szűk keresztmetszet... Sok cikket olvastam, és korábban a reiser, most meg az XFS a kedvenc. Általában is kerülöm a nagyon friss dolgokat, jó ha valamit már 10 éve hajtanak.. mégiscsak a filerendszer...

TF112 2009.10.12. 17:28:42

fs nélkül h lehet használni? gondolom ez a raw.

bagoj ur 2009.10.13. 12:25:16

Azt ingyen megmondtam volna, hogy az ext3 fog nyerni... :) Bár nekem csak 8 magig volt letesztelve, mert ilyen erős vas nem volt a kezeim között.

blackshepherd · http://suckit.blog.hu 2009.10.13. 16:29:54

@bagoj ur: Más területen viszont jobbnak mondják az újakat...

v.l 2009.12.20. 21:29:42

hightechsorcery.com/2008/10/evaluating-performance-ext3-using-write-barriers-and-write-caching

ugye vagy ki volt kapcsolva a diszkeken a write cache, vagy volt barrier=1 mount opció az ext3-nak? mert különben egy gyors, ámde életveszélyes konfigurációt találtál leggyorsabbnak, ami nem túl meglepő, de csak a jó backuppal rendelkezőknek merném ajánlani...

a zfs pl. tudja kezelni azt, hogy van write cache a diszkben, sőt, ki is használja. a btrfs és az ext4 eleve nem teszi lehetővé a barrier nélküli vakrepülést.

Scythe 2011.10.21. 17:19:23

@TF112: Mivel ext3 is naplózó fájlrenszert ezért a barrier-el a naplózást lehet ki/be kapcsolni. Nélküle kb. ext2 szintjén van.

v.l 2011.11.03. 23:16:43

@TF112: A barrier annak a megvalósítása, hogy a fájlrendszer garantálni tudja, hogy az A és a B írás közül a B nem történik meg, amíg az A nincs a diszken (tehát egy crash esetén nem fordulhat elő, hogy a B kikerült a diszkre, de az A írás elveszett).
A megoldás pofonegyszerű: az A és a B írás közötti tartunk egy mesterséges szünetet (ez lesz a barrier), azt mondjuk az oprendszernek, hogy akkor kezdhet neki a barrier utáni írásoknak, amikor a barrier előtti összes írás már diszkre került. Ez kell minden journalling fájlrendszer, és minden log-based adatbáziskezelő rendes működéséhez.
A barrier-re egyáltalán nincs szükség, ha az írásokat nem puffereljük, azaz ha az oprendszer akkor jelzi csak az írás elkészültét, ha az valóban a diszken van (write-through üzemmód). De ez meg baromi lassú tud lenni.