Turbo módba kapcsolt az ftp.fsn.hu!

 ( bra | 2009. február 1., vasárnap - 15:39 )

Turbo módba kapcsolt az ftp.fsn.hu, köszönhetően a Suntól tesztelésre kölcsönkapott Sun Storage 7210-es "OpenStorage" diszkdoboznak.

Az itt lévő konfigurációban 64 GiB memória, két darab AMD Opteron 2356 (egyenként négy, 2,3GHz-es mag, 512k/2M/2M L1-2-3 cache), 47 darab 7k2RPM-es 500 GB-os diszk, és egy 18GB-os írás-optimalizált SSD van:


A 7210-es alapja egy Sun X4540-es, amelyre egy speciális, NAS funkciókra kihegyezett OpenSolaris került. A NAS funkció itt a beépített NFS (v3, v4), FTP, HTTP és iSCSI szervert jelenti, kiegészülve olyan extrákkal, mint a vírusszűrés, vagy az NDMP támogatása. A NAS alapját képező szerver önállóan és SAS diszkdobozként is kapható.

A 7210 képességeiről hamarosan külön cikkben is megemlékezünk, addig is pár statisztika-képernyő a gépről, miközben ftp.fsn.hu-ként funkcionál.
Az első sorban a hálózati forgalmat (MiBps), a doboz CPU terhelését, a ZFS ARC statisztikát, a diszkek IO terhelését (MiBps), az NFS iops statisztikákat, és a diszk IO statisztikákat láthatjuk, miközben a kiszolgálás mellett pár tükör szinkronizálása is zajlik:

Megfigyelhető, hogy a ZFS "bevárja" az írásokat, és azokat nagy adagokban küldi ki a diszkek felé. Látszik az is, hogy az adatok frissítése (mirror szinkronizáció) miatt az ARC data hits értéke meglehetősen alacsony, a cache-ben leginkább csak a metaadatoknak marad hely.

A második sor szintén a fenti statisztikákat mutatja, de már akkor, amikor "lenyugodtak" a dolgok, azaz kevés sync fut csak:

Itt jól látszik, hogy a közel 60 GiB memória-cache-be azért már több minden belefér, a kérések jó része onnan kerül kiszolgálásra.

A 7210-es elé belógatott FTP/HTTP/rsync frontend egy ASUS desktop alaplappal futó, 3,2 GHz-es Pentium D (még a P4-es korszakból) CPU-t és 2 GiB memóriát tartalmazó vacak, két alaplapi Broadcom gigabites interfésszel (egyiken a 7210, másikon az internet).

Aktuális terheltség:

last pid: 17576;  load averages:  0.74,  0.44,  0.51    up 0+16:24:40  13:58:38
131 processes: 1 running, 130 sleeping
CPU:  4.5% user,  0.0% nice, 15.2% system,  0.8% interrupt, 79.5% idle
Mem: 603M Active, 987M Inact, 317M Wired, 17M Cache, 213M Buf, 54M Free

pinky# netstat -w 1
            input        (Total)           output
   packets  errs      bytes    packets  errs      bytes colls
     53027     0   45433734      52709     0   52481952     0
     51618     0   44832753      51419     0   51493931     0
     55224     0   48309703      54436     0   52903814     0
     57973     0   51059085      55787     0   54950348     0

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A "kölcsönkapott" mennyi időt jelent?

http://www.sun.com/tryandbuy/

Idézet:
Próbálja ki termékeinket 60 napig ingyen, majd vásárolja meg 20–40%-os árengedménnyel!

A jövő héten szerintem visszamegy, még mások is kíváncsiak rá...

Addig okvetlenül próbáld ki a ráüvöltős trükköt is.

De ez azt jelenti, hogy ha mindenki megnézte, visszakapjátok, és végre megint gyors lesz az ftp.fsn.hu?
Mi amugy pont valami hasonló megoldást keresünk, de ezekről eddig nem is hallottam, storageban nincs nálunk sun, inkább emc, meg hp. Főleg a nagyobb testvére, a 7410 érdekes, nagyon igéretesnek tűnik...

Kíváncsi vagyok a részletesebb tesztre isés szerintem nagyon jó, hogy így "menet közben" ki lehet próbálni!

Nem, ez sajnos nem azt jelenti, bár kétségtelenül kitörő örömmel fogadnék egy ilyen támogatást a Sun részéről. Gondolom ők is szívesen adnák, ha jól megy a szekér, úgyhogy ezen legfeljebb azzal tudsz segíteni, ha odamész, veszel pár ilyen dobozt, a számlát elfaxolod a Sun Mo-hoz, és ráírod, hogy: plusz egyet kérnék az FSN-nek is.
;-D

tyű...
jöhetne egy nekem is :)

lol ..
pont a napokban szedtem ki a sources.list-böl mert elég gyakran nem elérhető.
Azért hajrá :)

pfff
mi a jo ebben a gepben? pfff
szar amd, -||- sun, -||- zfs, -||- nfs, -||- opensolaris.. soroljam pff

ja annyi a jo h ingyen van..

--
1&2

[troll]igazad van. bubuntu ext3-al sokkal jobb lenne.[/troll]
Mi is a bajod pontosan?
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

rossz valasz. attol meg hogy ez a sun-os cucc lehet eleg jo, az ubuntu es az ext3 sem szar. nem is hiszem hogy ugyanaz lenne celkozonseguk.

- Use the Source Luke ! -

tudom én ezt. Csak úgy látszik más nem tudja.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

ujjak vagyok erre?

--
1&2

Nem vagy ujjak, se kezek, se lábak. ;)

Milyen ujjakat keresel? Gyűrűs, hüvelyk, mutató?

KAMI
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

ki maradt 1 t :p

szal arra celoztam h meg itt nem hallotam jot sunrol

--
1&2

ki maradt 1 t :p

LOL

moss fulet

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Pedig a mostani (x86-os, a SPARC a mi területünkön halott, bár a Niagara széria még visszahozhatja) gépeik egyértelműen az eddigi legjobbak a vállalat fennállása óta. :)

Esetleg valami konkretum vagy csak jol esik a sardobalas?

-- Soha ne vitatkozz idiotakkal! Lesulyedsz az O szintjukre es legyoznek a rutinjukkal !!! --

Gép: ez egy jól összerakott, és mint látható sokoldalú (használhatod natív SAS/SATA-n is, ha pedig teszel bele FC HBA-t, akár úgy is elérheted) vas. Ekkora diszksűrűséget szerintem senki más nem rakott még össze. 48 diszk 4U-ban azt jelenti, hogy egy rackbe belefér majdnem 1 PB bruttó kapacitás, ami *nagyon durva*.
Ennek a gépnek leginkább a bitlapátolás a feladata. A jelenlegi Intel CPU-k a cérnavékony buszaikkal nem biztos, hogy feltétlenül jó választás ilyen helyre.

Szoftver: bár én azt gondolom, hogy a ZFS-ben bőven van még hely az optimalizációra (és a funkciókra is), az látszik, hogy egy ilyen gépen aranyat ér. Tudom, nehéz felfogni a linuxos magánzárkából azt, hogy milyen jelentősége lehet egy L2ARC-nak brutális SSD-kkel, hiszen ott ez még csak álom, ahogy sok más is.

Az NFS olyan, amilyen, mindenesetre jelenleg ez az egyetlen olyan protokoll a unixok körében, amely elérhető és általánosan használható. A nagyobb testvére pedig az SPoF problémát is megoldja a clusterrel.

Persze senki sem gátol meg abban, hogy Linuxot, vagy bármi mást tegyél rá (bár erre nem érdemes, csak a standalone dobozra, hiszen itt a szoftver is pénzbe került), csak minek.
Ez egy NAS, amit a Sun a már meglévő szoftvereiből alakított ki, ahelyett, hogy a többiekhez hasonlóan valami proprietary szart fejlesztene.

Sajnos nincs ingyen, fizetni kell érte. :(

Idézet:
Ekkora diszksűrűséget szerintem senki más nem rakott még össze. 48 diszk 4U-ban

Ez 25 darab disk kettő uniton. Csak egy disk a difi, de akkor is bee... :-P
Persze ebben nincs intelligencia, ha pedig hozzácsapok egy Proliant-et hogy valami használja is a tárkapacitást, máris túlnövök a 4U-on. Másik hátránya pedig hogy a 2.5"-os diskek okán nem fogad 300GB-nál nagyobb tárkapacitásuakat.
Mindazonáltal király ez Sun storage, kár hogy esélyem sincs ilyet kipróbálni.

Ave, Saabi.

Van jópár ilyenünk, ismerem, köszi. :)

A diszksűrűséget természetesen 3,5-es diszkekre kell érteni, nyilván egy ugyanilyen konstrukcióval (top load diszkek három rétegben egymás alatt), 1,8-as diszkekből még az MSA70-nél nagyobb sűrűséget is el lehetne érni.
De azt hiszem azt bátran kimondhatom, hogy egy 3,5-es diszk maximális kapacitása mindig is nagyobb lesz/lehet, mint a 2,5-esé.

2,5-es diszkből pedig van nagyobb, mint 300 GB-os, legfeljebb a HP nem forgalmazza. :)

Ti nem szoktatok bekérni a konkurenciától tesztgépeket? ;)))

Idézet:
Ti nem szoktatok bekérni a konkurenciától tesztgépeket?

De, biztosan. Csak én nem találkozom azokkal. Supportos vagyok, nekem a saját termékeinket kell ismernem.

Ave, Saabi.

Azt hiszem egy ilyen portfólióval inkább lennék Sun supportos, mint ***-s. :)
Előbbinél lassan csak a unixot kell ismerni, utóbbinál meg azért egy rakás különféle firmware nyűgjeit (legalábbis a low(-mid?)range storage fronton).

(csak viccelek, nem kell vitatkozni :)

OFF
Bra, a T-online reverse DNS tesztelőgép cache-t használ a DNS feloldáskor? Hiába javítottam a hibát a teszt dél óta mindig hibát ad..
ON
Jó az az AMD..

Igen, igazából az nem tesztelőnek, hanem hiba URL-nek készült.
Meg kellene már azt is csinálni. :-O

Ha továbbra sem megy, írj a postmaster@-ra.

Köszi! Mail megy.

ha pedig teszel bele FC HBA-t, akár úgy is elérheted)
ez felkeltette a kivancsisagomat.
Milyen fc kartya ami egyaltalan hajlando magat target modba rakni
milyen driver ami kepes meghajtani az fc target drivert
milyen szerver, ami kepes fc targetet adni

mert elvileg ok, hogy ez lehetseges, a klasszikus FC storageket sem ufok hajtjak belulrol. Csak konkretice tenyleg-e.

COMSTAR, (Open)Solaris

Ha pedig a solarisos cuccnál is beváltabbat akarsz, nézd meg ezt:
http://scst.sourceforge.net/

Én Qlogic HBA-kkal használom, jó.

- Szar AMD, hat hidd el, hogy ok jobban tudjak, hogy mit raknak egy gepbe, mint te :).
- Sun, hat hidd el, hogy igenis jo dobozokat gyartanak, de miutan megnezel parat kene velemenyt alkotni rola.
- ZFS, vegulis csak nehany fanatikus BSD-s, meg linux-os akarja hogy portoljak a kedvenc oprendszerukre, annyira keveset tud.
- Opensolaris: Ezzel is mi a bajod?

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

troll vagyok

--
1&2

64 GiB mindenre elég! :D

Ezt en maskepp hallottam:
"640 Kb mindenkinek eleg lesz" :)

-----
“Firefox, you say? No I don't play Pokémon”

Kilo... Giga... Ott van az... Nem szabad elakadni ilyen apro reszletkerdesen :}}


Sic Transit Gloria Mundi

Köszönöm, én ezt szoktam használni minden disztribhez. Hajrá :-)
________________
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 4 Gb ram, x86_64 2.6.28-gentoo-r1

Megneztem a picasa kepeket, es 1 dolgot nem ertek: te vagy a Noe, vagy az egyeb 200 lako kozul az egyik? :-))

http://picasaweb.google.com/nagy.attila/20080728Nebassz#5231742331154023138

SPAMtelenul - POP3 spamszuro szolgaltatas

Van harmadik lehetőség is: csak arra jártam.
De sajnos én a 200-ból vagyok egy...

Van negyedik lehetőség is: te vagy a hölgy, akinek zoknit kellene dugni a szájába. :D

Hunger drágám, muszáj lebuktatnod ennyi ember előtt? :)

A női sikolyokból én egyből tudtam! :P

Próbáltál már kiabálni vele? :)

( http://www.youtube.com/watch?v=tDacjrSCeq4 )

--
"Dude, you can't take something off the Internet.. that's like trying to take pee out of a swimming pool."

Erről a videóról 2 dolog jutott eszembe. Egyik, hogy fizikai munkások ilyen zajban már fülvédőt hordanak:D
A másik pedig, hogy lehet nem is kell szuper napkitörés, hogy tönkretegye az elektromos berendezéseket? Mármint ha egy ilyen rákiabálástól ennyire "kileng", akkor egy nagyobb földrengés esetén elszáll minden adat, nem?

--
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..." - Douglas Adams
"I can't win, but I can fight! And I make your life miserable."

Örülök, hogy tetszett. Megér 14 milliót?

Ez erősen listaárnak tűnik. :)
Raktam össze alkatrészekből jópár hasonló (bár ilyen sűrűségűt nem, mert nincs ilyen ház) dobozt, és azt kell mondjam, hogy ez annyira egyben van, hogy ha van rá pénz, eszembe nem jutna barkácsolni.

Egyébként anno kiszámoltam, és ha tényleg venni akarsz ilyet, olcsóbbra jön ki, mintha megvennéd darabokban (ház, alaplap, CPU, memória, kontrollerek, diszkek stb), leginkább azért, mert ilyen házat egyszerűen nem kapsz a piacon, így ugyanekkora kapacitás kétszer, háromszor nagyobb helyigénnyel jön ki (és ennyiszer több ház, CPU stb, hacsak nem valami SAS-os megoldást lapátolsz össze).

Igazából a diszkek árán van elrontva a dolog, kár, hogy nem lehet ilyen cuccot venni diszk nélkül, csak kerettel mondjuk 4-5 millióért, a TB-os diszket meg megvenném bele a sarki boltban 40 ezerért. :)

Ugrana is rögtön a support. :)

--
"- The question is: what is a mahna-mahna?
- No. The question is: who cares?"

Szerencsére eddig olyannal nem sok kapcsolatom volt. Garancia, esetleg vmi. care pack, hogy egy helyett három, vagy három helyett öt év legyen, a support árán meg veszünk kettőt egy helyett.

kikellett volna rakni az (x) jelet, akkor nem nyitottam volna meg feleslegesen

udv Zoli

(x), mint fizetett cikk/hirdetés?

Miért tettem volna ki olyat, ha egyszer ez nem az?

ha nem hirdetes akkor csak e-penis lengetes kategoriaba sorolhato. azt hittem hogy vegre javul az ftp frissitesi uteme, de sajnos nem

udv Zoli

Helyzet az, hogy én is kipróbáltam volna szívesen. Abban is egyetértek veled, hogy a dicshimnusz az reklámízű. Ettől még, ha én kipróbálom 60 nap alatt sla miatt nehéz lett volna olyan környezetbe integrálni ahonnan el lesz vonva, másrészről az információk megosztása nem lett volna szabad. Ezért én örülök neki, hogy bra kipróbálta egy kvázi publikus szolgáltatáson, mert így látható mire lehet számítani. Így a reklámérzetet nagyban csökkenti a tény, hogy örül, hogy jól sikerült a publikus teszt. Én várom azt a részletes cikket ahol leírja a tapasztalatait is. Pl. miért ilyen kevés a hálózati terhelés... Próbálta e nfs-en kívül valamire...

A dicshimnuszra azért majd alkalomadtán rámutathatnátok, konkrétan a cikkben egy szóval sem minősítettem a terméket, pedig tényleg k.va jó. :)

NFS-en kívül másra nem próbáltam, mert ahol mi alkalmaznánk, csak ez szerepelne. A beépített FTP és HTTP szerver engem nem vonz, mivel ilyen dobozt elvből nem tennék ki a frontvonalba.
Ami érdekes lehet még, az a CIFS és az iSCSI. Előbbinél is leginkább az ID mapping, amely hasznos lehet vegyes (Windows-UNIX környezetben).
Ez utóbbi nekünk még érdekes is lett volna, viszont ki azért nem próbáltam, mert:
- nincs meg hozzá a windowsos infrastruktúrám és tudásom
- egy ilyen összerakása jóval több időt vett volna igénybe, mint amennyi nekem volt (LDAP, AD, szerverek felhúzása, koncepció kialakítása, szóval a tesztkörnyezet és a tesztfeltételek kitalálása, megépítése)
- ahol én használni tudnék ilyet, hogy kb. 2-4 millió külön kvótázható userre kellene méretezni, ami a ZFS sajátsága miatt nem épp reális

A miért ilyen kevés a hálózati terhelést nem értem. Ennyi az ftp.fsn.hu forgalma jelenleg egy jó diszkdobozzal, más meg nem nyúzza a dobozt, hogy nagyobb legyen.
A tesztek során a 4 Gbps-t majdnem 100%-osan (van ugye protokollveszteség is) ki tudtam belőle húzni, kb. 40-50%-os CPU terheléssel. Azok, akik 10GE-s interfésszel terhelték majdnem egy GB-ot tudtak olvasni belőle másodpercenként, ebben sajnos nem volt 10GE-s adapter, de ha lett sem tudtam volna hová dugni, mert a "laborunkban" nincs még ilyen, 10GE-t még csak az access layer uplink portjainál használunk.

Basszus, hol van már az előző évszázad, amikor 100 Mbps forgalom elmondhatatlanul soknak számított, most meg 50 megabájt másodpercenként kevés...

"A dicshimnuszra azért majd alkalomadtán rámutathatnátok, konkrétan a cikkben egy szóval sem minősítettem a terméket, pedig tényleg k.va jó. :)"

Attól, hogy nem írod le szó szerint, lejön. (nem nézted ki mi? :) )

"NFS-en kívül másra nem próbáltam, ...."

Engem iSCSI érdekelt volna ilyen tesztnél.

"A miért ilyen kevés a hálózati terhelést nem értem. ..."

Amit leírtál most, arra lettem volna kíváncsi, de ez nem látszott a grafikonokon.

"Basszus, hol van már az előző évszázad, amikor 100 Mbps forgalom elmondhatatlanul soknak számított, most meg 50 megabájt másodpercenként kevés..."

Nos tudod ez az utóbbi 3 évben változott sokat, de itt ugye nem normál hálózatról beszélünk hanem diszkhozzáférésről és itt mint közvetlen adatelérés mást jelent.

Most mit mondjak. Nem tudok róla, hogy lenne még egy ehhez hasonló doboz a piacon, így azt hiszem érthető, hogy tetszik.
Majd ha lesz mihez hasonlítani, megtesszük, de amennyire tudom erre még nincs mód.

Az iSCSI olyan langyos témának tűnik, ahol konkurrens elérés kell, az NFS jobb lehet, egyébként meg még mindig szinte mindenki FC-zik, vagy ha olcsóbb (és nem feltétlenül konszolidált) megoldást akar, SAS-on SATA-zik.

Engem eddig nem győzött meg a technológia, szerintem nem is ebbe az irányba kell menni...

Nyilván mást jelent, de azt gondolom, hogy 50 MBps hálózati forgalom egy desktop pécéből még ma sem feltétlenül olyan rossz, azt pedig ne felejtsük el, hogy mögötte ez a 7210-es azért jelentősen többre is képes.

Sajnos ennek mérése viszont már korántsem egyszerű dolog, hiszen mindenkinek más a fontos, ráadásul több gép között összehangoltan, pontosan IO-t mérni, hát nem feltétlenül öröm. :)

A régi helyeken megmarad az FC és ha kell persze jó az csak drágább az új helyen is, de az iSCSI felhasználása szélesebb rétegnek adatott meg, emellett nem igazán körvonalazódik alternatíva.
Nem mondtam, hogy rossz az 50MB/s, csak ha tesztelsz, akkor maximumra szokták a tesztet nyomni..

Ez igaz, bár azok, akiknek "megadatott" az iSCSI már évek óta tudtak valamilyen saját (nem IP-be dugott SCSI) protokollal hálózaton blokkos eszközöket használni...

A maximum olvasásban itt látszik:

kép

Itt azért kibukik, hogy a ZFS azért kér is valamit azért, amit ad. Másik gépen egy ZFS vs. UFS (FreeBSD) tesztnél is látszott, hogy még ha kikapcsolok minden csilivilit (pld. checksum), a ZFS akkor is több kernelidőt fogyasztott, mint az UFS.

Abban teljesen igazad van, hogy 50 MBps egy diszktömbtől nudli, és abban is, hogy 470 MBps is nudli 48 diszkkel (ez utóbbi szekvenciális volt), viszont ez NAS, ahol a 4xGE is korlát volt, az 50 MBps pedig tényleg az ftp.fsn.hu forgalma, ahol most nem a gép(ek) teljesítménye, hanem az igények limitálnak (ennyit töltenek, nem többet).
Erre céloztam, hogy amikor 2000 környékén helyet kerestem a gépnek, a Matávneten kívül mindenhonnan elhajtottak, amikor megtudták, hogy 4-8 Mbps nemzetközi forgalma van a gépnek lefelé, felfelé pedig lenne neki 20-40 is, ha engednék (nem engedték volna).
Akkoriban ennyi volt összesen egy közepes ISP-nek, most meg 50 MBps-t keveslünk. :)

Magának a gépnek a teljesítményét közvetlen rajta futó OS-sel lehetne megnézni, olyanról mintha olvastam volna, hogy valami MD-vel meg Linuxszal próbálkozott hasonlón, és végül rájött, hogy jó neki az a ZFS. :)

Sok ügyfelünk használja Linux-al. Messze nem olyan jó, de nem tudom lebeszélni róla őket. :/

Majd a btrfs. ;)
Mire használják?

statikus képek közösségi site-hoz
videomegosztó
online piactér (gondolom ott is képek)
egyéb khm.. tárhelyszolgáltatók.

Múltkor windows 2008-al akarták, de nem tudott sok mindent. (pl raid level) Megmutattam opensolarisban milyen egyszerű megcsinálni a tömböt, főleg a hiperszuper x4540-raid-kalkulátor XLS-emmel :), úgyhogy az lett rajta, az a vas a héten élesedik, ha lesz idő.

Nincs baj a linux-al se, csak teljesen kaotikus a device naming, halál idegesítő emiatt az egész md téma, meg ennyi sávnál szerintem kell az intelligencia, amit a zfs csinál írásilag meg ARC-ilag.

Ahogy én láttam van még optimalizálási lehetőség bőven ZFS és sok diszk témakörben. :)

Várj, hirtelen nem tudom mit is vársz. 1998-99-től kb. 4-5 évig nagyrészt a saját fizetésemből (nagyobb támogatások: az LME által vásárolt nyolc ATA-s diszk, és az (ex-)Axelero Rt. támogatásai) volt ftp.fsn.hu (és más dolgok). A mostani a HUP olvasói, és az (ex-)Axelero Rt. támogatásából jött létre.

Kenyér helyett megint diszkeket kellene vennem, vagy csak a bankszámlaszámot nem találod? :)

Kicsit off és valószínűleg rtfm de:
"Itt jól látszik, hogy a közel 60 GiB memória-cache-be azért már több minden belefér, a kérések jó része onnan kerül kiszolgálásra."

Ez azt jelenti, hogy lehetséges az, hogy induláskor betöltsek egy filet a memóriába és azt onnan és ne a winyóról hívja elő?
Vagy félreértem?
Ha nem akkor hogyan kell ezt megoldani?

http://bigacsiga.net

Ez tudtommal teljesen automatikus. Persze ha van egy rakás adat, amit te mindenképpen szeretnél a memóriában tartani, létrehozhatsz egy ramdisket, amibe bersync-eled a fileokat a diskről. Csak arra kell ügyelni, hogy előbbi automatikusan sync-el, utóbbi meg nem. Tehát időnként érdemes futtatni egy rsync-et, hogy a ramdiskből visszaszinkronizáld a fileokat a diskre.

Szvsz ez automatikus.
tudod, cache.
a gyakran használt cuccokat bennt hagyja a memóriába.
nem ramdisk, hanem cache.

egyik megoldas a ramdrive, de mintha a filerendszer is cachelne memoriaba, plusz ha van raid vezerlo annak is lehet sajat memoriaja, csak legyen alatta battery.
ha hulyeseget irtam majd az okosok kijavitanak.

Tyrael

buffer

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

először berántja a vinyóról, utána meg a ramból adagolja, kb. de ez nem új találmány. cache a neve.

Azért a ZFS esetében ez nem feltétlenül ilyen egyszerű:
http://blogs.sun.com/brendan/entry/test

Ahhoz képest, hogy milyen egyszerű és kézenfekvő az ötlet, csodálkozom is, hogy miért nem találta ki ezt senki korábban.
Hány és hány helyen segített volna egy lassú ATA-s diszkekkel megtömött storage előtt egy pár gyors 10k-s SCSI diszk read cache-nek, és journalnak (na ilyen volt) visszafelé (metaadat, esetleg adat)...

ez érdekes, köszi.
egy kérdés: olyan helyen, ahol tíz és tíz Gbyteok vannak ramban, miért van naplózó filerendszer? nyilván redundáns táp + szünetmentes van, szóval áramszünettől nem kell félni.
szóval azt akartam mondani, hogyha elszáll valamiért, akkor már olyan mennyiségű adatot buksz a cache-sel, hogy az már régen rossz. (jó, ha van journal, akkor az fs még egyben marad, különben meg fsck napokig.) de mi a valószínűsége hogy elszálljon mindkét táp vagy mindkét szünetmentes egyszerre...

A táp azért még mindig nem életbiztosítás sok helyen, másrészt pedig a gép is lerohadhat (szoftverhiba, de a hardver is kinyúlhat, ezek nem lockstepes geoclusterek).
Journalt lehet egyébként adatról is vezetni, az pedig egy pörgős SSD-vel már elég komoly biztosítékokat tud adni.
A metaadat-journal pedig még segíthet is a teljesítményen, hiszen lehet, hogy mire kiíródna, már le is törlöd a fájlt, vagy a sok kis random írásból tud csinálni pár nagy folyamatosabbat.

Mi tehát a kérdés? :)

nincs kérdés :)
köszönöm

mintha irta volna multkor valaki hogy belotte a nemtommilyen fajlrendszernel az adat sata-n, a metaadat/journal meg ssd-n talan.

Tyrael

Itt áll előtted. ZFS, a SATA-s diszkeken van az adat, a 18 GB-os DRAM-os SSD-n pedig a ZFS ZIL-je (metaadat-journal).

akkor jol remlett.
szar a nevmemoriam. :)

Tyrael

és akkor még lehetne benne ARCL2 is..

Lehetne, de nincs. Mindenesetre ez a 18G-s SSD igencsak jófajta, FreeBSD alól csináltam vele egy egyszerű raw dd-t, 130-140 MBps jött le róla...
Az írást nem próbáltam, nehogy megszeppenjen tőle a cucc, pedig az is érdekelt volna.

Márpedig próbálnod kellett volna, az az SSD egyáltalán nem olvasásra van optimalizálva, jóval több rámegy írásban. de van olvasásra való is: 100 gigásak és 3000 iops-t tudnak ("Readzilla")

Tudom, végignéztük már a portfóliót. :)
Az a 3000 nem 30 ezer? ;)

Ha azt mondja a marketing akkor annyi, de én egyébként 3100-at láttam benchmarkon. Persze a blokkméret is számít

mi hasznalunk egy ilyet elesben, amit en kovettem el fuseval, es lattunk egy eleg jo terhelhetoseg-novekedest :)

bar a fishworksos sracok jobban vagjak a temat, mint en, szoval kudos nekik zfs fejlesztesert :)

Ez melyik program is lenne? Mondjuk azért nem biztos, hogy ezt fuse-val oldanám meg. :)

nem opensource, cegen beluli fejlesztes. ki kene dobni opensourceba, csakhat nem rajtam mulik. arra akartam celozni csak, hogy az otlet jo dolog, es mukodik.

ez a 480mbit amugy komolyan a maximuma a diszktombnek? mert akkor elkezdek sirni :) raadasul seq readnel..?

Egy darabig gondolkoztam azon, hogy kellene csinálni hasonlót GEOM-mal, de aztán rájöttem, hogy mire végeznék vele, úgyis használható lesz a ZFS is, tehát minek. :)

Igen, de ha precízek akarunk lenni MiBps, azaz 470*1024^2 bájt per sec. Ha kicsit matekozol, és megnézed, hogy 4 darab GE interfésze van, talán még az okára is rájössz. :)

jahogy byte. ugy mar rogton mashogy fekszik a neni :) a tobbi meg overhead a tobbi layerbol, gondolom.

randomban mennyit tol? :)

#define random.
Elindítottam egy iozone-t 8 T-ig, de valahol mindig lerohadt, ráadásul több tíz gigánál már nagyon lassú egy-egy menet.

Itt találni néhány főbb mutatót a Sun Storage 7000 dobozok teljesítményéről:

  • Streaming : 1 GB/s on server and 110 MB/sec on client
  • Random Read I/Os per second : 150 random read IOPS per mirrored disks
  • Random Read I/Os per second using SSDs : 3100 Read IOPS per Read Optimized SSD
  • Synchronous writes per second : 5000-9000 Synchronous write per Write Optimized SSD
  • Cycles per Bytes : 30-40 cycles per byte for NFS and CIFS
  • Single Client NFS throughput : 1 TCP Window per round trip latency.

Brendan Greg pedig kimérte a 7410 határait:

  • NFS streaming read from DRAM ~1.90 Gbytes/sec
  • NFS streaming read from disk 1.04 Gbytes/sec
  • NFS streaming write to disk 563 Mbytes/sec
  • NFS read IOPS from DRAM 281,000 IOPS

Persze a való életben ennél kevesebbre számítsunk.

Miért számítsunk kevesebbre a való életben? A 150 random iops teljesen korrekt. Readzilla iops - tényleg annyi. Sustained 600 mbyte/sec write-ot pedig az x4540 is tud akár "default" konfigban.

Igen korrekt, de a gyakorlat ritkán produkál ilyen szép szekvenciális vagy éppen random terheléseket vagy éppen 100%-os cache hit arányt. Az eredeti "disclaimer" fent van a linken a pontos mérési módszerrel együtt.

"I should make clear that these are provided as possible upper bounds - these aren't what to expect for any given workload, unless your workload was similar to what I used for these tests. Click on the results to see details of the workloads used."

Pont azt mondom, hogy a "gyakorlatnak" nem kell produkálnia semmit, a 600mbyte/sec-et nálam bárhogy viszi - 10 klienssel vagy 1000-rel, teljesen mindegy.

Én pedig pont azt mondom, hogy ez szép eredmény és hogy a gyakorlati 600mbyte/sec nem azonos a fenti "elméleti" benchmark eredményekkel.

elkéstem :)

Ahhoz képest, hogy milyen egyszerű és kézenfekvő az ötlet, csodálkozom is, hogy miért nem találta ki ezt senki korábban

eleg sokan csinaltak. Eloszor mainframe, aztan high-end, aztan midrange kategroaiban volt elerheto mindenfele eleresi ido - tarterulet egyensulyozas: memoria, ssd, gyors diszk, lassu diszk, jukebox (floptical), szalag.
A komolyabbak 4 szintet, a kevesbe komolyak 3 szintet az egyszerubbek 2 szintet tudtak.

Az ssd jouraling sem uj otlet, az ssd fogalma is igen regi, ssd 20 eve is volt (akisval megtaplalt dram). Az ssd-ben a tomegesen elerheto, olcso flash az uj, mint ahogy a ZFS ketszintu cache rendszereben is az olcso, tomeges elerhetoseg az uj, nem pedig az, hogy tobbszintu es jo.

Egyebkent ez a tobbszintu dolog a midrange-bol akkor kopott ki, amikor a diszkek kapacitasa/ara ugy bekozelitette a szalag/floptical kapacitasat. Es az az elenyeszo kis sebessegtobblet, amit a 7200 RPM diszkek cachelese 15000 rpm diszkekre jelentett, nem erte meg a bonyolult algoritmus karbantartasat. Most az ssd (cost/iops, cost/capacity) es a diszk (cost/iops, cost/capacity) aranyai igen erosen kulonboznek, most megeri a dupla caching algoritmusst fejleszteni/karbantartani. Amennyiben az ssd es a diszk cost/iops aranya egymasbacsuszik (nem fog) vagy a cost/capacity lesz hasonlo (erre van esely) akkor megint ertelmetlen lesz a ketszintu caching.

Egyebkent hotdata, colddata. Klasszikus perf. management tanacs, hogyha van egy diszk tombod, mondjuk 2000 iops es 2.5 Tbyte, es van hotdata 1950 iops igennyel, 100 mega (nagyon-nagyon fontos), es 2 T colddata (nem fontos), akkor osszerakhatod ezt a kettot erre a meregdraga raidre.

akkor ez volt az a gép, amiről freebsd-current@-en írtál, a boot problé,ával kapcsolatban
___
info

Ja, sajnos senki sem vette a fáradságot, hogy felvegye a szálat. Diszkre telepítve megy, csak a pxe loadert kefélték el sikeresen. Sajnos az újabb más gépen sem bootol, viszont ott legalább a régi megy, itt viszont egyik sem...

Pedig szívesen csináltam volna egy OpenSolaris vs. FreeBSD ZFS összehasonlítást. :)

zfs freebsdn azert meg eleg kiserleti jelleggel mukodik

telleg ha mar itt tartunk mennyi a max kmem 64bites fbsdnel?

--
_

kosz
--
_

Én nem sok mindent szedtem erről az ftp-ről, de mivel volt rajta ./testfiles/.. könyvtár amiben jó nagy fájlok, így írtam egy scriptet amivel a net sebességét lehetett tesztelni. Most meg már nem megy, mert eltüntek a fájlok. :(

Helyette van speedtest.net, vagy még 10 másik amivel ugyan úgy lehet sebességet tesztelni.

Biztos unta bra az állandó, fárasztó kérdéseket, hogy miért tárol a drága storage-on értéktelen sok terás fileokat. :))

Pár napig még gyereknap:
-rw-r--r-- 1 0 0 1152921504606846976 Jan 31 22:18 1EiB
-rw-r--r-- 1 0 0 1125899906842624 Jan 31 22:17 1PiB

Én csalódtam a ZFS-ben, mert nem sikerült zettabyte méretű filet létrehoznom, csak 8 exabyteosat... :(

:)

Az ember azt gondolná, hogy a ZFS már tényleg jó mindenre, aztán egyik nap eszébe jut egy olyan apróság, hogy az eddigi házi videóit összefűzi egybe és belefut ilyen korlátokba... :\

igazabol az van, hogy felismerte azt a szemantikai hibat, hogy a loporno nalad mar a very hard kategoria, es ezert nem engedte.. ;)

Mindenesetre valakinek nagyon kellene a kollekció, mert délben (hátha pont kajálok? ;) rátolt egy komplett Nessus scan-t a hunger.hu-ra, sebezhetőséget keresve... :P

te sebezhetosegnek hivod a lovas porno gyujtemenyedet? :)

Tyrael

ff megint 2x postolt, hurra opensource ;)

Akkor az én iceweasel-em biztos nem opensource, ez még soha nem fordult elő vele.

Minek szivatod magad? Használj Internet Explorert, Safarit vagy Operát. A Firefox használata még nem kötelező, szerencsére. :-)

Ave, Saabi.

mostanaban ugy allunk, hogy az IE tobbszor fagy be sok tabbal, mint az ff. cserebe az ff elzabalja a memoriat :)
most inditottam, csak hup van epp nyitva, es 40 megat eszik..

persze, ez nem sok igy. de aztan mikor 400, az azert mar.. :)

2^64 -1, eleg nagy filemeretnek.
konkretan kicsit tobb, mint amenyi wincsesztert idaig valaha legyartottak :-)

Darabra vagy össz kapacitásra? Mert 1 byteos winchestereket nem gyártottak soha, úgyhogy darabra nincs sok értelme számolni... :)

tehat?
:-)

Tehát marad az össz kapacitás, ott meg a kijelentés nem áll fenn (arról már nem is beszélve, hogy amit írtál [ 2^64 -1 ] sem helyes, mert valójában - a képen is látható módon - csak 2 ^ 63 -1. Biztos signed. :P)

1) http://www.metrics2.com/blog/2006/10/04/top_two_hard_disk_drive_makers_control_more_than_5.html
98.6 million disk drives shipped worldwide in the second quarter

98,6 millio diszk fel ev alatt

azt becsulom, hogy most tobbet gyartottak, mint egy evvel ezelott, es ez igy megy mar egy ideje. Tovabba azt becsulom, hogy a 20 evvel ezelotti (es az azt megelozo) diszkkapacitas elhanyagolhato
tehat 3944 millio diszk. 1 diszk maximum 1.5 Tbyte.
Ez 3944 * millio * 1.5 * Tbyte = 5916 * 10E+6 *10E+12 =cca= 6 * 10E+21
ez nagyjabol 2^72 on nyert, nem is kevessel.
grrr, esz a mereg. csinaljunk pontosabb becslest, mert ez most bosszant :-)

Közel egy évvel ezelőtt volt hír, hogy a Seagate túl van az első milliárd eladott merevlemezén. A gyártó akkor sajtóhírben jelentette be, hogy ekkora mennyiséghez 29 évre volt szükség, de számításaik szerint a következő egy milliárdos darabszámot már öt éven belül elérik (ebből ugye eltelt már majdnem az ötöde). Azt is írták akkor, hogy az eddigi winchesztereiknek össz kapacitása 79 millió terabyte. Ez volt majd' egy éve és ugye ez egyetlen gyártó csak, igaz jelenleg a legnagyobb, de így is csak a teljes piac egyharmada az övé... Na, kalkulálj ;)

seagate= 30% (idoben konstans feltetelezes)
79 10E+6 Tbyte = 79 10E+18
szumma = 100% :
2.6 10E+20
2^64 =cca= 2 10E+19

ez igy nezve 10-szer annyi (egy evvel ezelottig).

barhogy is nezem, ehez a 64 bit cimzes tenyleg kicsi:-)

A 79 millió terabyte már így is majdnem a 10-szerese a max. méretnek (8 millió terabyte = 8 exabyte) és szerintem arra jön még rá a többi... :)

Az érdeklődőknek ajánlom a Storage 7000 admin guide online HTML vagy letölthető PDF változatát. Mindössze 244 oldal szép screenshot-okkal.