Mennyivel erőforrásigényesebb a ZFS?

Fájlrendszer, NAS, storage

A ZFS-ről sokan tudják, hogy erőforrásigényesebb, mint más (általában egyszerűbb) fájlrendszerek, azonban a nagyobb igény mögött általában a memóriát szokás elsősorban érteni. De mi a helyzet a CPU-val?

Fogtam két, egymással mindenben azonos gépet, és kipróbáltam mindkettőn ugyanazzal az operációs rendszerrel egyidőben ugyanazt a terhelést (a gépek terheléselosztó mögött vannak, így ez nem okozott problémát).

Hardver:
1xIntel 5130 (2 GHz, dual core) CPU, 8 GB RAM, HP P400 vezérlő BBWC-vel, rajta 8 db. 15k-s SAS diszk
Szoftver:
FreeBSD 8-STABLE (kb. egy hónappal ezelőttről), és postfix

A gépeknek semmi más dolguk nincs, mint benyelni, és kiküldeni a rajtuk keresztül folyó e-maileket.

Az első képpár az UFS-es (bal oldali) gép CPU terhelését mutatja, mellette az azonos időszakban, azonos terhelés mellett a ZFS-es (jobb oldali) gépével. Mindkét fájlrendszernél az atime ki volt kapcsolva, UFS-nél soft updates, ZFS-nél pedig az alapértékeken túl a tömörítés (lzjb) volt bekapcsolva.

A második képpárnál a különbség (azon kívül, hogy máskor készült, és így némileg más volt a terhelési görbe) abban van, hogy a ZFS-nél kikapcsolásra került a tömörítés.

Mint látható, a gép idejének nagy részét a kernelben tölti, az első ábrán átlagban 37,71 (UFS) és 58,83 (ZFS) százalékot, ami több, mint másfélszeres (1,56-szoros) különbség a ZFS hátrányára.
Tömörítés nélkül az arány kicsit jobb, 1,53-szoros.

A checksumozás kikapcsolásával az arány tovább javítható (kb. 1,43), azonban ezzel pont a lényegét veszti el a ZFS.

A fentiek természetesen nem általános érvényű számok, a postfix elsősorban metaadat-műveleteket végez (fájlokat mozgat/töröl a queue könyvtáraiban), így leginkább ezt a részét stresszeli a fájlrendszereknek (pld. jogosultság, ACL kiértékelések, stb).

ui: csattanóként a két gép fogyasztását tettem volna fel, és abból kiszámoltam volna, hogy évente mennyibe kerülne ZFS-t használni, de a ZFS-es gép mérőkéje megzakkant, és konstans 38 Wattot mutat, ami a másik gép 249 Wattját tekintve teljes blődség (a notebookom fogyaszt kb. ennyit).

( Kayapo | 2010. 04. 06., k – 20:59 )

Érdekes!
Milyen RAID-del voltak összefűzve a diskek? (gondolom ez is azonos volt). Nagyjából mennyi file mozgott a kérdéses időszakban?
----
概略情報

Igen, RAID10, mindkét gépnél a RAID vezérlő által (azaz a zpool egy darab virtuális diszkből állt) összefogva.
Naponta olyan 2-3 millió levél megy át, ez azt jelenti, hogy egy levélnél minimum:
incoming -> active queue könyvtárak közti mozgatás van, majd delete,
rosszabb esetben az active után még deferred, majd onnan active és ez amíg ki nem megy.
Azaz van bőven fájlművelet.

( hory v | 2010. 04. 06., k – 21:22 )

Igazabol a 12 magos cpu-k koraban nem az szamit, hogy mennyi cpu-t eszik egy FS, hanem hogy kepes-e multithreaded mukodni. CPU ido boven akad, ha ertelmes es hasznos feladatrol van szo.

Utálom ezt a "van víz/levegő bőven, fossunk hát bele vastagon" hozzáállást.
Minden pénzbe/energiába kerül, és másfélszer annyi CPU időt elégetni szerintem durva.
Az, hogy hány magos egy CPU lényegtelen, pontosabban a mostani alkalmazásoknál azért kijelenthető, hogy minél több magos, annál több veszteség keletkezik.
A lényeg az, hogy jelentős CPU mennyiséget elfogyaszt csak a fájlrendszer, még lényegesebb, hogy pld. az UFS-hez mérve (FreeBSD-ben legalábbis, nem kizárt, hogy Solarisban más a helyzet) másfélszer annyit.

Az pedig, ha több storage-ot tudsz ráakasztani egy gépre, mint amennyit a fájlrendszer CPU-val ki tudna szolgálni, akár kellemetlen is lehet. Két CPU-s gépet ma értelmes áron lehet venni, efölött már hatványozódnak az árak...

lBaltazar% uname -a         
SunOS lBaltazar 5.11 snv_134 i86pc i386 i86pc Solaris
lBaltazar% zpool upgrade -v
This system is currently running ZFS pool version 22.

The following versions are supported:

VER  DESCRIPTION
---  --------------------------------------------------------
 1   Initial ZFS version
 2   Ditto blocks (replicated metadata)
 3   Hot spares and double parity RAID-Z
 4   zpool history
 5   Compression using the gzip algorithm
 6   bootfs pool property
 7   Separate intent log devices
 8   Delegated administration
 9   refquota and refreservation properties
 10  Cache devices
 11  Improved scrub performance
 12  Snapshot properties
 13  snapused property
 14  passthrough-x aclinherit
 15  user/group space accounting
 16  stmf property support
 17  Triple-parity RAID-Z
 18  Snapshot user holds
 19  Log device removal
 20  Compression using zle (zero-length encoding)
 21  Deduplication
 22  Received properties

For more information on a particular version, including supported releases, see:

http://www.opensolaris.org/os/community/zfs/version/N

Where 'N' is the version number.

--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

A ZFS-t egyelőre az OpenSolarisban fejlesztik, így értelemszerűen mindig le van maradva. Kb. a Solaris állapotát próbálják követni, több-kevesebb sikerrel.

A ZFS szerintem kevés helyen tud kevesebbet enni, mint az UFS (egy három-négyszeres sorkülönbség biztos adódna, ha megszámolnánk a kettőt, már csak emiatt is), így a cikk címe jó. De várom a te méréseidet, találj olyan use case-t, amiben a ZFS kevesebb erőforrást fogyaszt. :)

ha már ekkora zöld környezetvédő lettél javaslom a MenuetOSt. pure assembly, minimális erőforrást vesz csak igénybe, zöld környezetkímélő operációs rendszer:)
az x86 és utóda az amd64 ma már úgyis de facto szabvány. de ha igazán minimál fogyasztású rendszert akarsz, akkor Arm, az sem fog eltűnni egyhamar:) bár kicsit munkaigényesebb portolni rá a MenuetOSt, mint más erőforráspazarlóbb rendszert, de legalább környezettudatos munka és jó móka:)
van olyan orosz ismerősöm aki még ma is úgy gondolja, hogy az Assembly A programozási nyelv, a többi csak szükséges rossz:D

ha adott feladat ellátásához kevesebb mint fele számítási kapacitás és memória elegendő, akkor adott gyártási technológia mellett kevesebbet fogyasztó computerek készíthetőek. egy teljesen assembly rendszer mellett a fele erőforrás több, mint szükséges.
a másik oldalon pedig olyan alkalmazás szintű technológiák, mint java vagy .net az üvegházhatás és környezetszennyezés fő bűnbakjai:D

Arra próbáltam célozni, hogy attól, hogy asm, még nem biztos, hogy a gép kevesebbet fog fogyasztani.
Ennek számtalan oka lesz, pld. ugyanúgy nem hatékony, vagy egyszerűen nem használja ki a gép power mgmt képességeit (lásd DOS, egyszerű, mint a faék, mégis 100%-on fogja pörgetni a CPU-t).

én pedig arra céloztam, hogy több szolgáltatás/egyszerűbb/gyorsabb feladatmegoldás több vasért nem feltétlenül rossz út. sőt nem is feltétlenül jelent energiapazarlást. ha Ghz habzsolás korszaka már le is járt, pár új cpu generáció után már marginális lehet a különbség. ma a zfs olyan képességekkel bír, amit semmilyen más fs nem tud, leszámítva a btrfst, csak az még under development. ezekért az előnyökért nem érdemes lemondani csak azért mert kicsit nagyobb terhelést jelent a zfs.
természetesen nem kell az utolsó routerbe is zfst erőltetni csak azért mert divat:)
megfelelő feladatra megfelelő fs.

érdekes lenne egy összehasonlítás OpenSolarison is. a zfs plusz képességeit ott is meg kell fizetni extra terhelésként, csak kérdés ott mennyi a különbség.

( bambano | 2010. 04. 06., k – 21:26 )

azt ki tudnád mérni, hogy amíg nem cpulimites a vas, addig melyik milyen io terhelést bír?

Ha egy eredetileg enterprise termék egy funkcióját nem hivatalosan portolnak egy másik termékbe, akkor szerintem megszűnik enterprise -nak lenni. De ha mutatsz egy céget aki freebsd szervereket árul zfs fájlrendszerrel, és minderre szerződést is aláír, akkor nem szóltam.

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

Nekem ez kicsit zavaros.
Ha a kernel "memóriakezelő rutinjait" használja, és úgy gondolod, hogy ez okozza a másfélszeres különbséget, akkor ebből az következik, hogy másfélszer annyi (kernel CPU időben mérve) memóriaműveletet kellene végeznie, mint az UFS, hiszen az is ugyanazokat használja. Jó, legyen ez. És ez min változtat?

Az utolsó is vicces, azért memóriaigényes, mert saját cache-e van? Milyen összefüggést látsz a kettő között?
Éppenhogy azért szoktak saját memóriakezelést írni az alkalmazásokba, mert annak írója tudja, hogyan használja a memóriát, és az általános célú allokátorok nem biztos, hogy olyan hatékonyan (sebességben, skálázhatóságban, kompaktságban) tudnak működni.

Nem, mert ez nem szintetikus benchmark, hanem éles gép. Nem én tolom bele a leveleket, nem tudom nekik azt mondani, hogy küldjetek annyit, amennyitől megfekszik.

Pont ebben van (számomra) az értéke, egy SMTP szerver queue-ját nehéz valósághűen modellezni (ha teszel egy bitsinket a másik végére, az ideális állapot, ez meg a valóságos).

Tedd fel a userek cimet nyilvanos helyre, esetleg iratkozz fel veluk 18+-as levlistakra. Igy meg tudod novelni a forgalmat. :)

Amugy ha az on-the-fly tomorites be van kapcsolva, es a proci megfelelo, akkor a kevesebb i/o muvelettel akar a fogyasztasa is lehet kedvezobb, mint akar tomoritetlen zfssel, akar mas filerendszerrel.

Ha a savszelesseg keves, akkor plusz winyok betetele helyett szinten lehet, hogy a tomorites (a prociido karara) kedvezobb.

Ettol fuggetlenul hasznos elemzes, koszi!

--
I can't believe Steve Jobs's liver is replaceable but the battery in my iPhone is not. - sickipedia

( Dwokfur v | 2010. 04. 07., sze – 07:28 )

Respect, hogy ennyit fáradsz.

Van egy gyanúm, hogy benne van a kezed a t-online levelezés szolgáltatásában: a greylist üzenetek árulkodóak.

FUN: nem tesztelnéd le nekünk ext4-gyel? :)

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Melyik is az az ext4? Ja, már emlékszem, az az, aminél múltkor beszoptam a következőt: openoffice autosave-elte a doksit, amit három napja írtam, majd utána kb. két másodperccel csonttá fagyott az egész finn gnu os (fingos). Sebaj, mondom nincs semmi veszve, hiszen volt autosave. Reboot, a fájl nulla hosszú.
Csólkoltatom Csót, igazán user friendly cuccot sikerült összehoznia.

"Helsinki (svédül Helsingfors) Finnország fővárosa és egyben legnagyobb városa."
"Linus Benedict Torvalds (Helsinki, 1969. december 28.) a népszerű, Unix-szerű operációs rendszer, a Linux fejlesztésének elindítója, jelenleg is egyik fő fejlesztője.
Szülei korán elváltak, Linust az anyja Helsinkiben nevelte fel. Anyanyelve a svéd, de finnül is anyanyelvi szinten beszél."

Ebben az esetben én sem vagyok magyar, hanem német, mert anyám révén sváb vérvonal van. De mivel itt születtem, itt nőttem fel (Linus Finnországban született, ott nőtt fel), így magyar vagyok (Linus pedig finn).
Ennek ellenére vallhatja magát svédnek, viszont azt se felejtsük el, hogy finnország közel 1/3-ának nyelve a svéd. Ugyanis hivatalosan is kétnyelvű ország.

Megelőztél, de valami hasonlót akartam írni én is.
Húgom Németországban született, nőtt fel, és él, de a magyar volt az első nyelv, amit megtanult.
Német állampolgár, azon kívül, hogy magyarok a szülei, és beszéli a nyelvet, semmilyen kötődése, kapcsolata nincs Magyarországgal.

Akkor most ő svéd, vagy finn?

Eddig csak Bélától, aki egyszer megkérte a kezem, de elutasítottam.

Az mondjuk érdekelne, hogy Torvaldsot mi alapján gondolod svédnek, mert ezek szerint ő ezt választotta (ami ugye egy elvi dolog). Kocsmázáskor mondta neked, vagy van valami hitelesebb is?

most őszintén: ki nem sz*rja le, hogy ki micsoda?
a lényeg, hogy ne legyen az illető cigány.
van egy holland üzletfelem, ádándon, siófok mellett van egy nagy telepe. töri a magyart, született holland, de itt él tizen-x éve.
multkor megkérdeztem, hogy Harm, te magyarnak vagy honnaldnak érzed-e inkább magad?
azt mondta, hogy ő Európai, de azért h beteg lesz, vigyék csak holland kórházba, viszont ezt az országot meg szereti.

pedig a holland kórházak is borzalmasak, tapasztalatból tudom. ha arrafelé orvosi ellátásra lenne szükséged, lehetőleg német kórházba kerülj, ha jót akarsz:)
Hollandia egyébként ezzel a nagy internacionalista hippi hozzáállásával azt érte el, hogy két évtizeden belül Holland Iszlám Szultánság lehet abból az országból. ui addigra többségbe kerülnek az iszlám bevándorlók és leszármazottaik.

( Dacr (nem ellenőrzött) | 2010. 04. 07., sze – 09:37 )

Köszönjük!

Ha esetleg a "mérőke" ismét helyrepofozódna, kiváncsian várom a csattanót :)

Jó ez az összehasonlítás.
Kimérted ,hogy ennél az alkalmazásnál felesleges a zfs mert nem kapnak
akkora terhelést a diszkek.
Igazad van ahol nem kell , felesleges energia pazarlás.
Az energia összehasonlítás akkor volna a korrekt , ha az UFS-nél
használnál valami röptömörítőt, mert a zfs-nél a tömörítés kikapcsolása
láthatólag nem spórol valami sokat.
Akkor megtudnánk ,hogy mi van akkor ha az UFS-nél akarnánk diszk i/o-t spórolni.

"Kimérted ,hogy ennél az alkalmazásnál felesleges a zfs mert nem kapnak
akkora terhelést a diszkek."
Definíció kérdése. BBWC-t jellemzően oda tesznek, ahol nagy pofont kapnak a diszkek, amit BBWC nélkül már el sem bírnának.
A ZFS meg ott nem felesleges, ahol nagy terhelést kapnak a diszkek? Nem értem a gondolatmenetet.
A tömörítést sem. Azért, mert az lzjb egy nagyon gyors, és erőforráshatékony valami, miért lenne korrektebb "röptömörítőt" használni az UFS-nél, és azzal összemérni? Elárulom: ha az UFS-ben is lzjb-vel tömörítenél ugyanolyan módszerrel, az arányok nem változnának. Meglepő? Vagy szerinted nem így lenne?

"A ZFS meg ott nem felesleges, ahol nagy terhelést kapnak a diszkek? Nem értem a gondolatmenetet."
Nézd van suzuki 1000-es és ferrari 412 is.
Ugye Ferrarit nem azért veszel ,hogy a városi dugóba gyök2-vel araszolj 60 liter benzint elégetve.
Viszont szeretnék 260-at menni a német autó pályán , hát az a suzukival nem megy.
Most mind 2 autó 80-nal megy.
Számomra nyilvánvaló ,hogy a Ferrari fog többet fogyasztani.
Vigyük határhelyzetbe a suzukit , mennek mind ketten 170-et.
A suzukinál a benzin fogyasztás aránytalanul nő , mig a Ferrarinál nem.
Terheljük már le azokat a diszkeket a raw tömbsebesség 80%-ra.
Vélhetőleg záródni fog a differencia.

"Elárulom: ha az UFS-ben is lzjb-vel tömörítenél ugyanolyan módszerrel,
az arányok nem változnának. Meglepő? Vagy szerinted nem így lenne?"
Nem értek egyet.
Akár milyen tömörítőt is használsz az CPU időt fog használni,
ami ugyan úgy növeli a villamos energia felhasználást.
De , tételezzük fel a következő helyzetet.
A tömörítésünk 50%-ot spórol a diszk I/O-n.
Van egy 4 magos 85W-os processzor , és van egy 4 diszkből alló tömb
melynek 10W/60W az üresjárat/terhelés fogyasztása.
A tömörítő egy teljes magot leterhel 100%-ra.
Akkor a CPU 21W + a diszkek (60-10)/2=25W összesen 46W.
A tömörítés nélkül a diszkek 60-10=50W.
Bekapcsolom a tömörítést mert spórol 4W-ot , spórol az amugy is szűkös diszk I/O-n ,
tároló területet takarít meg és vélhetően növeli a diszkek élettartamát.
SSD-s RAID rendszerek esetén a tömörítéssel már energiát nem takarítassz meg.

soha nem kellett dokumentációba áramfogyasztási adatokat írnom:)

mint írtam korábban a Google is eléggé sok szervert üzemeltet, mégis energiahatékonyság szempontjából rosszabb x86 szervereket használ. az IBM Power rendszerei optimálisabb választást jelentenének energiafelhasználás szempontjából, mégsem azokat használják. a Finnországba telepített szerverközpontjukkal ugyanakkor valóban sok energiát spórolnak.

Soktényezős ez a kérdés, és ha a Power (CPU) valóban energiahatékonyabb is (vannak konkrét méréseid is?), lehet, hogy összességében rosszabbul jönnének ki (mert a Linux x86-on jobban teljesít, mert a bekerülési költségek között akkora különbségek vannak, amelyek akkor sem térülnének meg, ha a Power fele annyit fogyasztana, mint az x86-os társa, mert az Intel sokkal kiszámíthatóbb, vagy dinamikusabb terméktervvel rendelkezik -minden évben drasztikusan javulnak a processzorai-, stb, stb, stb).

Én a cikkben próbáltam a tényekre támaszkodni, és nem kevés órát eltöltöttem már géptermekben fogyasztásméréssel. Neked mid van, azon kívül, hogy kijelentesz dolgokat, anélkül, hogy bármilyen ellenőrizhető módon alátámasztanád, vagy megindokolnád ezeket?

Kérlek ne hagyj hülyén meghalni: mi a jelentéktelen probléma szerinted, és milyen ostobaságokat írtam?

Itt van több ezer gép, az áramért, és a hűtésért komoly pénzeket fizetünk, szerinted egy 10-20%-kal magasabb számla jelentéktelen?

Komolyan, most vagy én vagyok nagyon eltévedve, vagy nektek nincs semmi közötök ehhez a szakmához.
Ha az előbbi, szeretnék tanulni (nem ciki beismernem, hogy valamihez nem értek, vagy rosszul tudtam eddig, senki sem mindentudó), ha utóbbi, akkor meg nem értem mire fel fogalmazol meg ilyen markáns (hmm) véleményt.

"Nézd van suzuki 1000-es és ferrari 412 is." [...]
Itt két fájlrendszerről beszélünk, amelyek közül az egyiknek valóban több szolgáltatása van, de ettől még a feladat ugyanaz. És ez a több szolgáltatás szerintem önmagában nem indokolja a másfélszeres teljesítményigényt.

"Terheljük már le azokat a diszkeket a raw tömbsebesség 80%-ra.
Vélhetőleg záródni fog a differencia."
Mi az a "raw tömbsebesség", és miért gondolod, hogy attól, hogy még jobban terhelem a fájlrendszert, változni fognak az arányok?

[tömörítős]
Te valami teljesen másról beszélsz. Én az arányokról írtam (ha ugyanazt a tömörítést használom UFS-nél és ZFS-nél, az arányok nem fognak jelentősen változni, az esetleges változás is legfeljebb az implementációs különbségekből adódhat), tisztában vagyok azzal, hogy ha tömörítést használok, az több CPU-t fog enni, ezért is volt egy tömörítés nélküli teszt.
Sőt, checksum nélküli is (amellyel használt feature-ökben így megegyezett az UFS és ZFS).

"Mi az a raw tömbsebesség ?"
A raw tömbsebesség az amikor file rendszer nélkül méred meg a tömböd áteresztő képességét(pl:dd).

"több szolgáltatás szerintem önmagában nem indokolja a másfélszeres teljesítményigényt."
Igazad van .

"miért gondolod, hogy attól, hogy még jobban terhelem a fájlrendszert, változni fognak az arányok?"
Én azt gondolom , hogy a ZFS nagyobb teljesítményű FS és ,nem csak több ,a szolgáltatási listája.

Lehet tévedek , nincs mivel megmérnem.

Nem tudom sikerült-e célba jutnia a következő információknak:
- itt két fájlrendszer került összehasonlításra, bitre azonos gépen, bitre azonos terheléssel
- kb. nulla diszk IO van, minden cache-ből működik

Na ha ez leülepedett, áruld már el, hogy az eredeti hozzászólásodban mégis mit akartál mondani azzal, hogy a raw tömbsebesség 80%-ánál záródni fog a differencia. Ha a raw tömbsebességben a saját definíciód nélkül nem érintett a fájlrendszer.

"Nem tudom sikerült-e célba jutnia a következő információknak:"
Igen lejött.

"kb. nulla diszk IO van, minden cache-ből működik"
Ezennel a zöldek nevében követelem a feleslegesen pörgő diszkek kikapcsolását !
A méregdrága RAID10-es tömb csak van ,és feleslegesen eszi a drága energiát,és szennyezi a környezetet.
Tegyél be egy darab 2,5" diszket , tömörítés sem kell. Ezt az is birni fogja.
Tegyél rá fat16-ot az lehet még kevesebbet fogyaszt a CPU-ból. :) :) :)

Viccet félretéve arra szerettelek volna rábírni , hogy tényleg terheljük már le a
diszkeket , hogy lássuk akkor mik az arányok.
Neked meg van a lehetőséged , nekem nincs.
Így lenne kerek a történet.
Mert így most csak annyi tudunk hogy a ZFS nem a cache-hez lett kitalálva.

Megkértem egyik kollegát , hogy az Open Sollaris-án méregessen egy kicsit.
Az alaphelyzetben átlagban ,ott kb 1,4x-es több cpu-t használ a ZFS.
A gépben egy 2magos proci és 2db raid0 tömb van.
A konektornál mérte a gép által felvett teljesítményt.
ZFS esetén kizárólag csak akkor mért alacsonyabb fogyasztást az UFS-nél
amikor azon tömbre amire írt ZFS volt ,és a tömbök közöttük másolt nagy fáljokat.
Már egy szál esetén is látszott.
Alapban ezen a gépen az UFS előnye 16-20W.
Teljes terhelésen a ZFS előnye 10-12W.
Teljes nyugalomban a fogyasztás 170-175W legnagyobb fogyasztás 276-282W
Tehát igazad volt,átlag használat mellett ,hacsak nem kell okvetlen valamelyik ZFS
feature vagy a gép nem cinema warez , akkor elég sok energia megy pocsékba.
De bogarat tettél a fülembe ,meg fogjuk nézni linuxal,bsdvel,és windowsal is.
Melyik a legzöldebb OS,és FS.

Remélhetőleg hamarosan ilyet is tudok, de megvárom vele az ubuntu releaset, biztos, ami biztos. :)
Az ftp.fsn.hu-n is ZFS van már, és ott bár teljesen eltérő a workload (jellemzően olvasás, tulajdonképpen streaming, csak sok streammel, így a valóságban random io), pont ezt a kb. másfélszeres CPU terhelést látom (márc. közepétől):
http://stats.fsn.hu/freepark.org/ftp.freepark.org/cpu-year.png

( dash | 2010. 04. 07., sze – 16:16 )

subscribe
---
Ami a windowsban szarrágás, az linuxban hegesztés.
Ha megszeretted a windowst, tanuld meg használni!
A linux igenis felhasználó-, és NEM idiótabarát.
A linuxot mi irányítjuk, a windows minket irányít.

( Arbiter | 2010. 04. 08., cs – 11:20 )

Bra, ha nem nagy meló és nem sajnálod tőlünk az infót, megosztanád velünk a lemez I/O teljesítmény adatokat is? Engem pl érdekelne, hogy teljesít a diszk alrendszer (IOPS, throughput, stb.)

Nem túl látványos, mivel egy ideje már ki van herélve a postfixből az összes sync. Itt nem gond, ha tízévente elkallódik három levél, mikor áramszünet van, vagy nyolcévente másik négy, amikor lerohad/megpusztul valamelyik gép.

Most, hogy a teljes queue belefér memóriába (korábban nem fért), az olvasások teljes egészében onnan vannak kiszolgálva, az írások pedig mennek a pufferbe, amit kedve szerint ürít mindegyik FS.