"cache-data-in-swap" támogatás érkezik a DragonFly BSD-be

Címkék

Matthew Dillon, a DragonFly BSD vezető fejlesztője a napokban bejelentette, hogy néhány kernel struktúra változni fog, ezért a fejlesztői ágat követőknek teljes kernelfordítást kell majd végezniük, nem elég az inkrementális. Matt emellett megjegyezte, hogy hozzájut néhány SSD-hez, ezért nekiáll implementálni egy "cache-data-in-swap" nevezetű funkciót.

Mint írja, az elmúlt évtizedben a gépekben ugrásszerűen megnőtt a memória mérete, következésképpen a swap használat lecsökkent. A legtöbb, nagy teljesítményű (web)szerveren kerülik a swap területre való lapozást, mert az jelentősen csökkenti a teljesítményt. Ebből kifolyólag a swap kevésbé hasznos, használatos ezeken a rendszereken.

Ugyanakkor az SSD-k elég kiforrottak lettek ahhoz, hogy adat gyorsítótárként (cache) funkcionálhassanak a merevlemezekhez. A merevlemezek mérete oly mértékben megnőtt az elmúlt években (2TB+), hogy a 4-16GB fizikai memóriát tartalmazó gépek nem igazán tudják hatékonyan cache-elni az aktív adatokat. Dillon szerint viszont a kisebb, mondjuk 40GB-os SSD-k óriási teljesítménylöketet adhatnának a nagy adatkészletekkel dolgozó rendszereknek, nem beszélve arról - írja -, hogy a régi szerverek vagy a kevésbé adatkiszolgálás célra kitalált munkaállomások, egyszerű vasak ilyetén való felturbózása sem elhanyagolható költséghatékonyság szempontjából.

Ezért Matt azzal foglalatoskodik ezekben a napokban, hetekben, hogy egy rendszerszintű cache-to-swap funkciót implementál olyan objektumok számára, mint a fájl adatok, fájlrendszer metaadatok.

A szolgáltatás - ha elkészül - lehetővé teszi a felhasználó számára, hogy az swap-ot telepítsen SSD-re, majd ezt a területet cache gyanánt felhasználja olyan "tiszta" és metaadatok számára, amelyek megtalálhatók a merevlemezen is. Ha az adat nem érhető el a fizikai memóriában, de elérhető az SSD-n, akkor a rendszer onnan fogja kiolvasni és nem a merevlemezről. Ez a szolgáltatás eltérően működik majd, mint a hagyományos swap-elés, hiszen akkor is működésben van, ha egyébként nincs memória szűkös állapot.

A mechanizmus előnye egy fájlrendszerbe integrált megoldással szemben az, hogy ez bármely fájlrendszerrel működik és, hogy ez a cache teljes mértékben eldobható.

Matthew úgy gondolja, hogy ez egy nagyon-nagyon zsír funkció lesz. Ráadásul az elmúlt időszakban végzett munkák gyakorlatilag tálcán kínálják a megvalósítás lehetőségét, hiszen olyan funkciók kerültek implementálásra az elmúlt hónapokban, amelyek lehetővé teszik a könnyű megvalósítást.

A beszélgetés során felmerült az SSD-k élettartamának, maximális írhatóságának problémája, de úgy fest, hogy Dillon erre is gondolt. Valaki felvetette, hogy nagy fordulatszámú SCSI/SAS lemezek is szolgálhatnának cache eszközként ebben az elgondolásban. Dillon egyetértett, azzal, hogy kissé különböző algoritmus felhasználásával szóba jöhet, sőt továbbfűzve a gondolatot, azt írta, hogy akár az NFS felhasználás is profitálhatna az elgondolásból.

A részletek Matt levelében olvashatók.

Hozzászólások

Ez a Dillon nem rossz arc, több ilyen kellene.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Ehhez hasonló megoldás létezik linuxra?

Feltéve, hogy a vezérlő IC-jükben ez jól van implementálva. Ami sajnos nem mondható el sem az USB flash stick-ekről, sem az SD kártyákról és sajnos a legtöbb SATA SSD-ről sem. JMicron vezérlő IC-k hírhedtek voltak a 100ms-ot is meghaladó írási késleltetésükről, ami még a merevlemezeknél is egy nagyságrenddel rosszabb. Persze kb minden SSD-ben ez a fajta IC volt, mert ez volt olcsó. Csak mostanában kezdtek bejönni a jobb vezérlők pl az Intel SSD-ken, de még mindig simán vannak piacon JMicron-os cuccok is. http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=2
---
Internet Memetikai Tanszék

http://www.mpieters.com/2007/01/readyboost-benchmark.html :)
Ellen pelda?

Szertintem nagyon hasonlo elkepzeles, csak a javaslatok listajan nincs ott, hogy hasznalj SD kartyat vagy USB -s cuccot :)

Szerk:
Itt egy teszt USB -vel.
http://www.anandtech.com/systems/showdoc.aspx?i=2917&p=6 , ha rendszer memoriajat 512Mb -re csokented van olyan teszt ahol eszrevehetetlen mertekben gyorsit.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

MS-nél megoldották, hogy, ha eltávolítod az eszközt mindenféle lecsatolás nélkül, akkor sem csuklik össze a renccert.
Fájlrendszer független és a cserélhető tároló behelyezésekkor teszteli, hogy a random olvasási sebessége eléri-e a küszöbértéket, ha igen, engedélyezhető.

Ezeket olvasgattam én is, illetve tesztelgettem (kérdés, hogy a PS vagy DW indulási sebessége mennyire releváns..).
Nálam 1 Gbyte RAM felett már észrevehetetlen volt a gyorsulás.

"MS-nél megoldották, hogy, ha eltávolítod az eszközt mindenféle lecsatolás nélkül, akkor sem csuklik össze a renccert."

Ez minden bizonnyal hardver/firmware függő is. Most elkirándulsz felénk, akkor mutatok neked két brand szervert, amire egy bizonyos külső USB diszket dugva olyan szép kékhalált dob a rendszer, hogy ihaj. Mind a két szerveren ugyanazt produkálja. Így feltételezhető az összeférhetetlenség. A külső lemezmeghajtók (4 darab) más gépeken tök jól működnek.

--
trey @ gépház

Ezzel nem nyirjuk ki az SSD-t 1-2 ev alatt?

Ha egy folytonos körbeforgó journal log formájában írja az SSD-re a lapokat, akkor nem, mert akkor garantáltan teljesen egyenletes lesz az összes cella felülírása. Függetlenül attól, hogy maga az SSD vezérlő mennyire ügyes/ügyetlen módon próbálja kiegyenlíteni az írások számát.
---
Internet Memetikai Tanszék

Ez nem olyasmi, mint amit a Sun már használ a storage szervereiben?

----------------
Lvl86 Troll

Pont az a lényeg, hogy nem! FS-ben van implementálva. A Sun által használt ZFS esetében a ZIL +az L2ARC-ot lehet akár SSD-re rakni. A végeredmény hasonló, csak Dillon megoldása elvileg rugalmasabb.

ZFS-es hybrid storage-ról egy kis olvasnivaló:

http://blogs.sun.com/studler/entry/zfs_and_the_hybrid_storage