Fájlrendszer levelező szerver alá

Web, mail, IRC, IM, hálózatok

Egy Debian alapú levelezőszervert kell összeállítanom, és érdekelne, ki melyik fájlrendszert javasolná hozzá. Kötött hardver, nem kell a bővítést támogatnia, csak minél stabilabb és gyorsabb legyen.
Én most az ext4 és xfs között vívódom, tudtommal mindkét fájlrendszer használható már éles környezetben is.Az ext3 ismereteim szerint nem szerette a túl sok fájlt egy mappában, de nem tudom, az ext4 ezen a téren hasonló-e? Az xfs jó a sok fájl kezelésében, így emiatt talán xfs a jobb? Cél, hogy több ezer mappa egy mappában ne legyen teljesítményrontó.
A tömörítés nagyon hasznos lenne a fájlrendszerben de nem tudom, mennyire stabil már. Tehát mindenféle tapasztalatnak, információnak örülnék.

  • 2294 megtekintés

( Kayapo | 2017. 07. 27., cs – 13:19 )

Gondolom az a kérdés, hogy a leveleket hogyan tárold, Ext4 -en, vagy XFS -en?

Én a magam részéről az ext4 -re voksolnék, az miatt, mert picit flexibilisebb. Sebesség beli különbséget, csak nagyon keveset fogsz találni (ez nyilván függ a hardware től is: minnél kissebb a hardware teljesítménye annál csekéjebb lesz a különbség).

Akár melyík mellett is döntesz, azt javaslom tedd külön meghajtóra a journal -t ehhez olyan meghajtót válasz ami első sorban szekvenciális írásban nagyon jó (A journal -t olvasni csak file vissza állításkor kell). Mivel az email fileokat random olvassuk és írjuk azok elérését (íráskor) lassítja a napló írása.

A filerendszer hangoláson kívül érdemes a mount paraméterekre is egy kis időt szánni. Javaslom a noatime, nodiratime kapcsolókat mindenképpen használni.

Érdemes keresni az "ext4 external journal" kifejezésre. Ha a tár terület storage -ról jön, akkor a filerendszeren és a storage -on használt blokk és csík méret (block size, stripe size) a filerendszeren, LVM -en, és a storage -on legyen összhangban.

Ne felejts el tesztelni, (pl iozone) a teszt fileok ne legyenek nagyobbak mint a legnagyobb megengedett levél mérete.

----
올드보이

A hardver adott, egy viszonylag friss gép, és a várható terhelés ismeretében nem fog szűk keresztmetszetet jelenteni. Egy darab hardver raid 1-es meghajtóval tudok garázdálkodni. A journal-nak külön partíciót csináljak, arra gondolsz? Még nem matattam a fájlrendszer journal beállításainál - őszintén megvallva, azt sem tudtam, hogy az nem a fájlrendszer része, és eltehető máshová.

Ha egy szál RAID1 -es tükröd van akkor nem érdemes külön tenni a journal -t. Ebben az esetben a stripe size adott, azt nézd meg, hogy az mekkora.
Nyilván, hogy érvényesüljön bármi amit a Perfor Manci -ért teszel ennek a VG létrehozatalakor ugyan annak kellett lennie, ugyan ez igaz a block size -ra is, DE az ext filerendszer max 4k -s blocknéretet tud, a raid vezérlők és a storage -ok ezzel megegyező, vagy nagyobb blockméretet tudnak létrehozni. (Szerintem oda nem is kell kissebb, manapság ritkán kissebb egy email ennél). Ezzel együtt esetleg meg lehet próbálkozni 2 vagy 1k blokmérettel.

Ugyan akkor szerintem fontosabb lesz neked, az mkfs.ext4 -T kapcsolója, meg a mount paraméterek.

----
올드보이

( tompos v | 2017. 07. 27., cs – 15:00 )

Amelyikhez TE jobban ertesz. Tokmind1.

( zeller | 2017. 07. 27., cs – 15:24 )

Perfor Manci kérdései: hány user, mekkora levélforgalom, milyen módon tárolódnak a levelek - utána lehet fs-t reszelni a szolgáltatás alá.

( dap | 2017. 07. 27., cs – 15:34 )

> ext3 ismereteim szerint nem szerette a túl sok fájlt egy mappában, de nem tudom, az ext4 ezen a téren hasonló-e

A dir_index ezt már ext3-on is megoldotta. Más kérdés, hogy ha régi volt a fájlrendszer, akkor még dir_index nélkül lett létrehozva és úgy valóban halál lassú volt nagy mappa esetén.

( Raynes v | 2017. 07. 27., cs – 17:54 )

„az ext4 és xfs között vívódom, tudtommal mindkét fájlrendszer használható már éles környezetben is”

Biztos vagy te ebben? Azért azt vedd figyelembe, hogy az ext4 még nagyon új, nem forrotta ki magát. Érdemes még vele várni 30 évet, addigra kellően stabil lesz, azzal nem kell foglalkozni, hogy mások addigra kvantumszámítógépeken fogják tolni az ipart olyan fájlrendszerekkel, amiről ma még talán nem is álmodunk, az az ő bajuk, ha veszélyesen akarnak élni.

Btrfs-t, ZFS-t különösen nem ajánlom, pláne mailszerver alá nem, azt olvastam, hogy bármikor lángba borulhat tőle a gép, vagy ha nem, akkor valamelyik amcsi hárombetűs cég rúgja rád az ajtót.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

( bucko | 2017. 07. 27., cs – 18:16 )

Vagy 10 évig üzemeltettünk egy szervert postfix+cyrus. A levelek maildir-ben. Később elő kellett venni a mentést, de korlátozott helyre. Az összes fs-t kipróbáltam, egyikre sem fért fel. Majd megcsináltam az eredetileg használt jfs-t. Arra felfért.
Ez csak egy tapasztalat, jöhet a hülyézés. ;)

Látom, sikerült megragadnod a lényeget!
Ha már így rákérdeztél, volt pénz is, vinyó is, csak a csavarhúzóhoz kellet volna 15-20 kiló métert utazni. :-D
Konkrétan a kolléga egy kis ssd-t tesztelt, amikor befutott a kérés. Gyorsan felrakott valami linuxot és szólt nekem, hogy mit szkripteljek. Erre csak éjjel volt időm. Annyi hely maradt, hogy rá kellett volna férnie az anyagnak, de nem tette. :( A mentést csak azért raktam vissza, hogy kéznél legyen, mert számítottunk újabb keresésre. Más esetben csak "röptében" kerestem volna a levelekben, a backup visszaállítása nélkül.
Pótkérdés?

( calamari | 2017. 07. 29., szo – 23:36 )

Tapasztalatból annyit tudok mondani, hogy ext4-re nyugodtan teheted, több száz gigás Cyrus folderrel sincs semmi baj vele.
Ha nagyon sok kicsi levél van akkor esetleg az inode sűrűséget (https://wiki.archlinux.org/index.php/ext4#Bytes-per-inode_ratio) érdemes lehet "fine tune"-olni.
Sebességnél meg szerintem nem ez lesz a korlát, legalábbis én úgy tapasztaltam...

♲♻♲