» »

HDD - neizbežne napake pri branju (URE)

HDD - neizbežne napake pri branju (URE)

MrStein ::

Že dolgo velja prepričanje oziroma ideja, da je po okoli 12 terabajtih prebranih podatkov z HDD napaka pri branju neizbežna (URE - unrecoverable read error AKA bye-bye my data). (viri spodaj)

Zanima me mnenje in izkušnje slotekovcev. V smislu:
- tak je
- neumnost
- moment, da preverim
- kaj drugega


http://www.zdnet.com/article/why-raid-5...
http://www.smbitjournal.com/2012/05/whe...
Oziroma celi kup: https://www.google.si/search?q=12tb+ure

PS: Je komu leta 2009 nehal delovati RAID-5? Ste prešli prej na kaj drugega?
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Miha 333 ::

Vsekakor so določene nevarnosti okrog tega. Mnenja se razlikujejo. Na primer, jaz se ne bi počutil dovolj udobno med rebuildom RAID-5 po odpovedi diska, zavedajoč se, da če se pojavi najmanjši problem med rebuildom, sem tako rekoč screwed. Ljudje oz. podjetja mi zaupajo hrambo podatkov in so življenjsko odvisni od tega. Še drug, indirekten odgovor: Obstajajo toliko boljše zadeve od enostavnega RAID-X za sranjevanje podatkov, da bi bilo nespametno jih ne-uporabiti.

Unilseptij ::

Že RAID 6 recimo, kjer imaš pač dva redundančna diska, je čisto OK za tak primer. Tudi ne razumem čisto, zakaj taka panika. Da pri RAID 5 ostaneš brez podatkov morata sovpasti dva dogodka, izpad enega diska in prisoten URE na enem od presotalih diskov v arrayu, ko delaš rebuild, kar pa konec koncev ni nič drugega kot izpad drugega diska med operacijo rebuilda, česar RAID 5 pač ne pokriva. Poleg tega bo večina kontrolerjev lahko vsaj delno obnovila tak okvarjen RAID in boš, razen zelo izjemoma, izgubil le tisti del, ki je okvarjen (torej določeno datoteko), ne pa kar vsega.

Vsekakor pa drži, da RAID 5 že dolgo ni primeren za diskovne arraye z velikimi kapacitetami (v TB), pa naj gre za veliko število majhnih diskov ali pa za majhno število zelo velikih diskov. Sploh pri enterprise rešitvah. Še vedno pa dela čisto OK za arraye do 6 ali 7 diskov z nekje do 1 TB na disk.

Miha 333 ::

Unilseptij je izjavil:

Poleg tega bo večina kontrolerjev lahko vsaj delno obnovila tak okvarjen RAID in boš, razen zelo izjemoma, izgubil le tisti del, ki je okvarjen (torej določeno datoteko), ne pa kar vsega.

Ne, večina kontrolerjev bo disk, s katerega ne more prebrati sektorja, izločila iz polja. Pri RAID-5 to pomeni, da je array neuporaben. RAID sistem ne ve ničesar o datotekah, niti o datotečnem sistemu, ampak samo predstavlja napravo operacijskemu sistemu, ki jo ta vidi kot običajen disk, zato kontroler nikakor ne more vedeti, kateri datoteki pripada sektor (če sploh datoteki, lahko tudi npr. praznemu prostoru).

RAID je dokaj primitivna zadeva, ki je dobro delovala v času manjših diskov. Danes obstajajo naprednejše rešitve.

Brane22 ::

Neumnost. Kolikokrat sem že skorigiral tak raid, tudi ne pomnim več.

Če bi bilo to res kar praviš, bi ga zgubil enkrat letno.

Ja, RAID ne ve ničesar o datotekah, ampak ti imaš možnost prečekirati ali je določen sektor v datoteki ali v prostem prostoru.

Kar se teh "naprednejših rešitev" tiče, sem se jih nagledal.

Koliko folka je modrovalo o BTRFS, nato pa je sledil plaz sesutij in prav debilnih zapletov.

Kar se ZFS-a tiče, afaik še vedno ni prosto v kernelu in GPL-x izvedba še vedno ne dohaja originala, pa tudi verjetno ni za vse potrebe, drugače bi bil default FS povsod.

Zgodovina sprememb…

  • spremenilo: Brane22 ()

Brane22 ::

Kar se UREjev tiče, so boljkotne iz riti potegnjeni.

1E-14 pomeni en bit na 10^13 byteov, torej v grobem 10TB.

Se pravi, če 2TVB drajv 5x prebereš, je znatna verjetnost, da ti drajv ne bo znal vrniti enega bita zanesljivo.

Neumnost, če mene vprašaš.

Sploh pri drajvih, ki imajo deklariran workload 500TB letno.

jype ::

MrStein> Zanima me mnenje in izkušnje slotekovcev. V smislu:
MrStein> - tak je
MrStein> - neumnost
MrStein> - moment, da preverim
MrStein> - kaj drugega

Definitivno se zgodi, ampak tega ne moreš opaziti.

Unilseptij> Že RAID 6 recimo, kjer imaš pač dva redundančna diska, je čisto OK za tak primer.

Ne, ni, ker praktično nobena implementacija RAID-6 ne preverja integritete podatkov.

Brane22> Neumnost, če mene vprašaš.

Kako pa preverjaš, če so vrnjeni biti enaki kot so bili zapisani?

Brane22 ::

Hash ?

Pa saj to ti že drajv pove. Vsak sektor ima ECC kode.

Ravno tako so različne kontrolne vsote pri prenosu.

URE ni naključna napaka pri prenosu ampak Unrecoverable Read Error.

Se pravi, drajv dobi napačen bit v sektorju, ki ga _ne_more_ popraviti.

Brane22 ::

jype je izjavil:



Kako pa preverjaš, če so vrnjeni biti enaki kot so bili zapisani?


Če misliš to za potrebe testa, folk je napisal simpl rutine, ki to omogočajo.

Če recimo odprem disk device in se sam s seboj zmenim, da vpišem v vsak sektor zaporedno številko sektorja, ki jo potem permutirano ponavljam skupaj z zaporedno številko recimo long longa znotraj sektorja, hasha ne rabim.

Folk je delal torture teste take in drugačne in je zlahka prišel čez to mejo.

jype ::

Brane22> Folk je delal torture teste take in drugačne in je zlahka prišel čez to mejo.

Saj ta meja ni nekaj, kar bi vgrajevali. To je educated guess, ki se spreminja s tehnologijami, vesoljskim vremenom in drugimi parametri.

Kar je obvezno je to, da se mora zgoditi.

l0g1t3ch ::

@Brane22

Sem videl loge od enega konkretenga storage sistemal, mislim da emc vmax, ki ima end to end preverjanje integritete pa je bilo vsak mesec nekaj zanannih in popravljenih napak.

Pa ne URE, v tem primeru se pač sektorja ni dalo prebrati in ga raid kontroler pač prebere iz drugega diska.
Šlo se je za napake, ko je sektor sicer uspešno prebran ampak je vrednost drugačna od tiste zapisane. Torej se je en bit flipnil. Sistem to ugotovi preko dodatnih checksumov na FS-ju in potem rekunstrira pravilno vrednost in tudi popravi zapis na disku.
In takih napak je bilo vsak mesec ene par.
Zdej če se ti flipne en bit v neki sliki ali spiratiziranem filmu verjetno ni panike. Kak piksel bo malo čudne barve ali pa kak frejm videa malo zatrokira.
Če pa imaš gor neke pomebne podatke je pa to lahko precej drugače.

Za običajne uporabnike dosegljive rešitve, ki zagotavljajo end to end integriteto so kolikor vem:
ZFS
BTRFS
REFS

Mislim da je od teh ZFS še najbol preverjena rešitev. In pa rabiš tudi ECC, če ne se ti še vedno lahko pokvari kaj v ram-u.
Je pa verjetno vprašanje koliko je to zares težava za domače uporabnike.

Zgodovina sprememb…

  • spremenilo: l0g1t3ch ()

Miha 333 ::

l0g1t3ch je izjavil:


Mislim da je od teh ZFS še najbol preverjena rešitev. In pa rabiš tudi ECC, če ne se ti še vedno lahko pokvari kaj v ram-u.
Je pa verjetno vprašanje koliko je to zares težava za domače uporabnike.

Pri ZFS je ECC ključnega pomena, ker se spomin uporablja za izračunavanje checksumov/hashov za ugotavljanje ter popravljanje integritete podatkov (na kratko povedano). ZFS brez ECC => smrt podatkov samo vprašanje časa.

l0g1t3ch ::

Sej verjetno je isto za BTRFS in REFS. Povsod se mora računati hashe in preverjati checksume so vsi ti podatki vsaj nekaj časa v RAM-u.

MrStein ::

Brane22 je izjavil:

Kar se UREjev tiče, so boljkotne iz riti potegnjeni.

1E-14 pomeni en bit na 10^13 byteov, torej v grobem 10TB.

Se pravi, če 2TVB drajv 5x prebereš, je znatna verjetnost, da ti drajv ne bo znal vrniti enega bita zanesljivo.

Neumnost, če mene vprašaš.

Čestitam. Prvi, ki je uporabil možgane.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

MrStein ::

BTRFS je beta (lepše povedano: v razvoju)

ReFS uporablja hash le če je na Storage Spaces (vsaj po defoltu, verjetno se da vklopiti tudi za "navadne" volume-je).

Microsoft je naredil test in prebral 700 TB brez napak (potem so test ustavili).

Po mojem je razvoje tega mita takšne:
To idejo so prvi omenili v znanstvenem članku o RAID, ampak so takoj dodali, da ni definirano, kaj točno URE tista številka pomeni. PREDPOSTAVLJALI so, da pomeni "v povprečju ena napaka na 12TB prebranih podatkov". Takrat so diski bili veliki 2GB s prenosi 10 MB/s in je to bilo zanemarljivo.
Potem pa so tisti stavek začeli ljudje ponavljati in je mit postal... legenda.
Redkokateremu pa se je posvetilo "hej, saj to trditev lahko preprosto preverim v nekaj urah". Ali minutah, če obstoječe loge preveri.

(viri pozneje, ker so na drugem PC)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

l0g1t3ch ::

Podatke za URE navajajo proizvajalci sami.

WD Re < 1 in 10^15 Non-recoverable read errors per bits read
WD Red < 1 in 10^14 Non-recoverable read errors per bits read

https://www.wdc.com/content/dam/wdc/web...
https://www.wdc.com/content/dam/wdc/web...

Ampa URE != bit rot.
V primeru da disk ne more prebrat sektorja bo to rešil raid in sicer tako da prebere iz drugega diska in življenje teče dalje.
Bit rot pa se dogaja ko disk sicer sektor prebere ampak je vrnjena vrednost drugačna od zapisane. Tu pa obični raid ne bo rešil ničesar ampak bo veselo posredoval napačno vrednost.

Seveda pa je vprašanje kako pogosto se dogaja ta drug scenarij, glede na evente loge enterpise storage omare, se to zgodi parkrat ne mesec amak tam notri je 100+ diskov ki 24/7 švicajo na polno.

MrStein ::

Še en zanimiv članek:
Why RAID-5 Stops Working in 2009 - Not Necessarily
(po komentarjih sodeč nekje iz leta 2012, datum samega članka ne najdem)

Citiram prvo poglavje, poudarki moji:
Suppose you were to run a burn in test on a brand new Seagate 3TB SATA drive, writing 3TB and then reading it back to confirm the data. Our standards are such that if a drive fails during 5 cycles we won't ship it. Luckily, all 20 of 20 drives we tested last night passed. In fact, most of the 3TB drives we test every week passed this test. Why is that a big deal? Because there is a calculation floating around out there that shows when reading a full 3TB drive there is a 21.3% chance of getting an unrecoverable read error. Clearly the commonly used probability equation isn't modeling reality.


'If data does not fit the theory then the theory is wrong.' - bi lahko rekli.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

l0g1t3ch ::

Ampak kot rečeno imaš sisteme, ki beležijo napake. Dvomim da bi se jih izmišljevali.

Čeprav po drugi strani te napake mogoče sploh nimajo izvora na samem disku, bit lahko flipne med prenosom po kablu ali pa v kakih sas expanderjih, itd... Da imaš ti 100+ diskov v eni omari je ogromno enega kablovja in vezij, da je vse to povezano.

Sedajle na najdem članka, ampak pisalo je nekaj na temo ECC znotraj samega diska in o uporabi Reed-Solomon algoritma.
V tistem članku je avtor prišel do sledečega zaključka (po spominu):
- če v sektorju flipne vsaj 1 in manj od nekega n, bitov (kjer je n neka zgornja meja koliko jih algoritem lahko popravi) -> ECC od diska ga ujame in popravi, kar se tiče raida kot da s ni nič zgodilo, disk je vrnil podatek
- če flipne več kot n, bitov imamo mejo m bitov (m>n) kjer algoritem zazna da je bila napaka in da je sektor nepravilen -> disk javi URE, raid potem prebere isti sektor iz drugega diska in popravi še sektor na prvem

Tako, da je bil kočni zaključek da bit rot-a na samih diskih ni oz je verjetnost neka absurdno nizka številka, za vse praktične pomene enaka 0.

pegasus ::

Absurdno nizka ne-ničelna številka? Za vse praktične namene "shranjevanja podatkov" je edina sprejemljiva številka 0. Sicer lahko redefiniraš "shranjevanje podatkov" na nekaj podobnega, kot to počnejo naši možgani - zelo slaba primerjava bi bil mp3 @ 32kBps. Lossy as f... ;) Če mi dovolite malo filozofiranja - pozabljanje je nekaj, kar enostavno moramo naučiti vse naše data storage sisteme, problem je samo, ker je pozabljanje vezano na tip podatkov in ga je torej težko do nemogoče implementirati kot nekaj splošnega. Mogoče nekoč ... trenutno je lažje preganjat bitrot in kupovat petabajte vsake pol leta.

l0g1t3ch ::

@pegasus

Obešaš se na detajle. Vem kaj hočeš povedati, storage sistem mora biti 100% ampak tist članek je govoril o enem disku.
In tam navedena številka je bila 10^-30 ali pa 10^-40. Skratka ne nič, pa hkrati tako majhna da je za realne namene lahko 0.

Je pa seveda to pogled tistega avtorja. Jaz po pravici rečeno ne poznam internega ustruja diska in njegovega ECC. Recimo da ga on je in da mu lahko verjamemo...

Ahim ::

l0g1t3ch je izjavil:

V tistem članku je avtor prišel do sledečega zaključka (po spominu):
- če v sektorju flipne vsaj 1 in manj od nekega n, bitov (kjer je n neka zgornja meja koliko jih algoritem lahko popravi) -> ECC od diska ga ujame in popravi, kar se tiče raida kot da s ni nič zgodilo, disk je vrnil podatek
- če flipne več kot n, bitov imamo mejo m bitov (m>n) kjer algoritem zazna da je bila napaka in da je sektor nepravilen -> disk javi URE, raid potem prebere isti sektor iz drugega diska in popravi še sektor na prvem

Tako, da je bil kočni zaključek da bit rot-a na samih diskih ni oz je verjetnost neka absurdno nizka številka, za vse praktične pomene enaka 0.


Saj to ni nikakrsen zakljucek, to so samo dejstva (tako pac algoritem deluje, torej do neke meje napako lahko odpravi, do neke visje meje pa je sicer ne more popraviti, jo pa lahko zazna, nad to mejo pa ne more zanesljivo narediti nicesar oziroma lahko nevede naredi se vecje sranje kot je ze bilo).

Ti potem iz tega vleces zakljucke (tudi v postu nizje) in navajas neke stevilke, za ketere ugibam, da si si jih izmislil.

Seveda bit rot pri diskih je problem, sicer bi bil edini izvor napak sele za bralno glavo (npr. zaradi kozmicnega sevanja itd.). Ce ga ne bi bilo, ne bi bilo potrebe po ECC shemi za zapis podatkov, ampak bi ECC uporabljali izkljucno na prenosnih poteh (kabli, kontroler), po katerih se prebrani podatki pretakajo.

l0g1t3ch ::

@Ahim.

Ne vlečem jaz nobenih zaključkov.
Tisti zaključki so bili na koncu članka in tudi številke so od tam (po spominu, gre se predvsem za velikostni red). Zaključek avtorja je bil ravno to, da je verjetnost dogodka da ECC ne bi mogel popraviti oz. vsaj zaznati in javiti napake praktično nič. Posledično da je vsaka skrb za bit rot na diskih odveč.
Ponavljam, to je zgolj en članek in mnenje tistega avtorja.

Imaš seveda tudi povsem drugačne, ki pravijo da je ECC na diskih ni dovolj in da se bit rot dogaja.
http://blog.fosketts.net/2014/12/19/big...

Ahim ::

l0g1t3ch je izjavil:

@Ahim.

Ne vlečem jaz nobenih zaključkov.
Tisti zaključki so bili na koncu članka in tudi številke so od tam (po spominu, gre se predvsem za velikostni red). Zaključek avtorja je bil ravno to, da je verjetnost dogodka da ECC ne bi mogel popraviti oz. vsaj zaznati in javiti napake praktično nič. Posledično da je vsaka skrb za bit rot na diskih odveč.
Ponavljam, to je zgolj en članek in mnenje tistega avtorja.

Imaš seveda tudi povsem drugačne, ki pravijo da je ECC na diskih ni dovolj in da se bit rot dogaja.
http://blog.fosketts.net/2014/12/19/big...


Bom se enkrat, ker ocitno prvic nisem bil dovolj jasen:

Kar je napisal avtor, so zgolj dejstva - tako pac delujejo ECC algoritmi, nic novega.

Ti si iz tega vlekel zakljucke v postu nizje v temi (kar mislim, da sem napisal?), zdaj si pa zraven privlekel se "velikostni red". Koliko pa je en velikostni red, ko zacnes operirati z intervali ("In tam navedena številka je bila 10^-30 ali pa 10^-40")?

In ce je "tako majhna da je za realne namene lahko 0" (kar je bil tvoj zakljucek), cemu potem sploh potreba po ECC?

MrStein ::

Ker brez ECC bi imeli 10^8 napak. (groba ocena, poanta je, da ECC "izloči" veliko večino napak).
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

l0g1t3ch ::

Ahim je izjavil:

l0g1t3ch je izjavil:

@Ahim.

Ne vlečem jaz nobenih zaključkov.
Tisti zaključki so bili na koncu članka in tudi številke so od tam (po spominu, gre se predvsem za velikostni red). Zaključek avtorja je bil ravno to, da je verjetnost dogodka da ECC ne bi mogel popraviti oz. vsaj zaznati in javiti napake praktično nič. Posledično da je vsaka skrb za bit rot na diskih odveč.
Ponavljam, to je zgolj en članek in mnenje tistega avtorja.

Imaš seveda tudi povsem drugačne, ki pravijo da je ECC na diskih ni dovolj in da se bit rot dogaja.
http://blog.fosketts.net/2014/12/19/big...


Bom se enkrat, ker ocitno prvic nisem bil dovolj jasen:

Kar je napisal avtor, so zgolj dejstva - tako pac delujejo ECC algoritmi, nic novega.

Ti si iz tega vlekel zakljucke v postu nizje v temi (kar mislim, da sem napisal?), zdaj si pa zraven privlekel se "velikostni red". Koliko pa je en velikostni red, ko zacnes operirati z intervali ("In tam navedena številka je bila 10^-30 ali pa 10^-40")?

In ce je "tako majhna da je za realne namene lahko 0" (kar je bil tvoj zakljucek), cemu potem sploh potreba po ECC?


Mislim da bom poskusil še enkrat in zadnjič. Lepo po točkah:
1. Nisem vlekel nobenih zaključkov, po spominu sem napisal kar je avtor članka zaključil.
2. Vse je pisano po spominu, ker članka sedaj ne najdem. Bi bil vesel če bi ga.
3. Omenjena verjetnost je verjetnost dogodka da ECC zataji. Torej da disk kljub internemu ECC-ju vrne drugačen niz bit-ov iz prebranega sektorja, kot pa je bil gor zapisan.
Ker bo ECC ali popravil napako če bo lahko ali pa vsaj javil napako. Tretja opcija da se sektor sicer prebere ampak so biti na njem tako "napačni" da ECC tega nikakor ne zazna je tista izjemno mala možnost za katero sem napisal številke.
4. ja velikostni red sem pa res napisal jaz, ker ne najdem boljšega izraza. Originalni avtor je napisal eno samo številko ampak meni se zdi isti K*** ali je bila 0^-30 ali pa 10^-40. Oboje je tako majhno da je za vse praktične namene enako 0. In to zadnje je bila sklepna misel članka.

In potem sem dodal še en link kjer pa drug človek pa piše drugače, da ECC-ju od samega diska ne gre zaupati.
Zdej pa se vsak sam odloči komu verjet.
Jaz se v stvari nisem poglobil toliko da bi dal prav enemu ali drugemu.

Zgodovina sprememb…

  • spremenilo: l0g1t3ch ()

Unilseptij ::

Odkod potem ocene za URE med 10^-14 in 10^-15, ki jih podajajo sami proizvajalci?

https://www.wdc.com/content/dam/wdc/web...

l0g1t3ch ::

Unilseptij je izjavil:

Odkod potem ocene za URE med 10^-14 in 10^-15, ki jih podajajo sami proizvajalci?

https://www.wdc.com/content/dam/wdc/web...


Jaz sem v člankih videl dve različni tolmačenji URE in sicer kot verjetnost za:
1. napako da javi disk da sektorja ni mogel prebrati pa ni važen razlog ali je to neberljiv sektor ali pa interni ECC zazna napako na prebranih podatkih, ki je ni uspel popravit
2. napako da je med biti ki jih je disk vrnil en napačen

Če velja prvo, potem te raid reši, če velja drugo, potem imaš silent data corruption in te reši samo ZFS in podobni FS-ji.

MrStein ::

Why Non-Uniform URE Distribution May Make Parity RAID Riskier Than Thought

Zanimivo, ker komentira dejstvo, da preizkusi kažejo veliko manjšo pogostnost napak.
Zaključek je briljanten: Ampak vseeno drži mit. Še bolj!
:)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

MrStein ::

MrStein je izjavil:


(viri pozneje, ker so na drugem PC)

Evo:

Chen et al, RAID: High-Performance, Reliable Secondary Storage (1994)
stran 160:
Currently, most disks cite uncor-
rectable bit error rates of one error in
10^14 bits read. Unfortunately, the exact
interpretation of what is meant by an
uncorrectable bit error is unclear.



Jim Gray, Catharine van Ingen, Microsoft Research:
Empirical Measurements of Disk Failure Rates and Error Rates 2005

The SATA advertised bit error rate of one error in 10 terabytes is frightening. We moved 2 PB through low-cost hardware and saw five disk read error events

5 napak, po mitu pi jih moralo biti 200.

Thus far, the System 1 read-only test has read 756 TB and seen no errors.

The drive specifications of UER=10^-14 suggest we should have seen 112 read errors.

Dejansko jih je bilo 3 (in še dva, ki pa sta uspela po retry-u)

Komentar na blog "Does RAID 6 stop working in 2019?" (2010)
http://storagemojo.com/2010/02/27/does-...
Citat:
"The population included several hundred drives across several build lots and capacity points and saw and actual URE rate greater than 10^18." - Ben March 1, 2010 at 8:07 am


Še nekaj o sorodni temu LSE:
Understanding latent sector errors and how to protect against them
Povzetek: LSE se zgodijo nepričakovano, ponavadi kot gruča in posledica enega dogodka.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Fizicni vs. software Raid (strani: 1 2 )

Oddelek: Strojna oprema
898912 (6086) MrStein
»

Kaj kupiti za shranjevanje 10T podatkov

Oddelek: Kaj kupiti
4711897 (9338) HighBane
»

Cene SSD-jev še vedno strmo padajo (strani: 1 2 )

Oddelek: Novice / Diski
9625479 (19828) darkolord
»

Opteroni za AM3+ vs FX-43xx poraba... (strani: 1 2 3 )

Oddelek: Kaj kupiti
13914706 (13124) filip007
»

Poliuranski klastri so molekularni magneti

Oddelek: Novice / Znanost in tehnologija
245317 (4227) AtaStrudl

Več podobnih tem