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

Sun Microsystems

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

( bimi3 | 2009. 02. 01., v – 14:25 )

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

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

( Smokey2k | 2009. 02. 01., v – 14:27 )

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

( sartek | 2009. 02. 01., v – 14:41 )

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

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. :(

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? ;)))

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.

- 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” :)

( cvk v | 2009. 02. 01., v – 14:45 )

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

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."

( willy v | 2009. 02. 01., v – 17:25 )

Ö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. :)

( colos | 2009. 02. 01., v – 17:47 )

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

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. :)

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.

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? :)

( bigacsiga | 2009. 02. 01., v – 18:10 )

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.

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? :)

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. :)

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.

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."

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.

( pinyo_villany | 2009. 02. 01., v – 20:18 )

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. :)

( btamax | 2009. 02. 02., h – 17:38 )

É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. :(

1) http://www.metrics2.com/blog/2006/10/04/top_two_hard_disk_drive_makers_…
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 ;)