Forum » Kaj kupiti » Vzdržljive Compact Flash kartice
Vzdržljive Compact Flash kartice
Brane22 ::
Gleda trpežnosti FLASHa proti sevanju takem in drugačne, ni videti da bi bilo to tu problem, sicer bi od teh doz crkavali ljudje in živina.
Kar se EM polja tiče, je tu AFAIK FLASH daleč bolj trpežen od recimo RAM-a.
Pravzaprav se FLASH based FPGAji prodajajo kot "SED immune" za letalske aplikacije itd.
Očitno je da motnja zjebe vdelani mikrokrmilnik in ne FLASH. In verjetno je, da motnja pride po kablih, mogoče kaj tudi po luftu...
Prehod na SLC je torej bolj kot predlog obsojenemu na ustrelitev naj se proba ščitit s tršo čelado...
kar se vpisa tiče, za zažiganjem blok-po blok ne dosežeš ničesar pametnega. Če vpisuješ cirkularno, je obraba ravno taka, ostane ti pa log preteklih vpisov, kot je pač kartica velika.
Kar se EM polja tiče, je tu AFAIK FLASH daleč bolj trpežen od recimo RAM-a.
Pravzaprav se FLASH based FPGAji prodajajo kot "SED immune" za letalske aplikacije itd.
Očitno je da motnja zjebe vdelani mikrokrmilnik in ne FLASH. In verjetno je, da motnja pride po kablih, mogoče kaj tudi po luftu...
Prehod na SLC je torej bolj kot predlog obsojenemu na ustrelitev naj se proba ščitit s tršo čelado...
kar se vpisa tiče, za zažiganjem blok-po blok ne dosežeš ničesar pametnega. Če vpisuješ cirkularno, je obraba ravno taka, ostane ti pa log preteklih vpisov, kot je pač kartica velika.
BlaY0 ::
Napisal sem da PC Engines prodaja tudi SLC CF kartice s SMI kontrolerjem, ki naj bi bile namenjene ravno takšnim pogojem. Po moje veliko bolje kot SanDisk Ultra, ki je namenjen bolj fotoaparatom in podobnim napravam.
Brane, mislil sem točno to kar si ti napisal. Bistvo pa je da zapečeš cel blok podatkov naenkrat in se šele nato premakneš na drugega. S tem zagotavljaš manual wear-leveling brez dodatnih abstrakcij, ki je v takšnih primerih najboljši. Jasno je da boš pisal cirkularno, kako pa drugače... pač ko ti zmanjka začneš od začetka in prepisuješ najstarejše. V bistvu delaš dvonivojski buffering podatkov pred pošiljanjem dalje po luftu.
Kot sem napisal, če se router obnaša OK, uporabiš pač takšne komponente, kot jih ima router in je stvar rešena.
Brane, mislil sem točno to kar si ti napisal. Bistvo pa je da zapečeš cel blok podatkov naenkrat in se šele nato premakneš na drugega. S tem zagotavljaš manual wear-leveling brez dodatnih abstrakcij, ki je v takšnih primerih najboljši. Jasno je da boš pisal cirkularno, kako pa drugače... pač ko ti zmanjka začneš od začetka in prepisuješ najstarejše. V bistvu delaš dvonivojski buffering podatkov pred pošiljanjem dalje po luftu.
Kot sem napisal, če se router obnaša OK, uporabiš pač takšne komponente, kot jih ima router in je stvar rešena.
Zgodovina sprememb…
- spremenilo: BlaY0 ()
Brane22 ::
Če bi to jaz delal, se ne bi zajebaval s karticami. Na mikrokonktroler bi počil NAND FLASH čip v zahtevani kakovosti direktno na isti PCB preko ONFI vmesnika.
Rešitev kot je uprabljena, se zdi totalen overkil - LEGO pornfest.
Nekdo je jemal gotove kocke in jih sestavljal v mozaik, ni pa upošteval njihove prave cene.
Filozofija je bila "who cares, če je stvar 1000x prekompleksna za to kar rabim, bom pač ostalo zavrgel."
Pa ni tko. To pali na tvoji domači mizi. Že če to zmontiraš v svoj avto, je pesem povsem druga.
kar naenkrat je cena de/montaže bistveno bolj pomembna od cene materiala, ko je ta na mizi.
Cena crkotja nekje na oddaljenem mestu in povezani servis pa prevlada obe prejšnji.
Posredni stroški pa njega.
Rešitev kot je uprabljena, se zdi totalen overkil - LEGO pornfest.
Nekdo je jemal gotove kocke in jih sestavljal v mozaik, ni pa upošteval njihove prave cene.
Filozofija je bila "who cares, če je stvar 1000x prekompleksna za to kar rabim, bom pač ostalo zavrgel."
Pa ni tko. To pali na tvoji domači mizi. Že če to zmontiraš v svoj avto, je pesem povsem druga.
kar naenkrat je cena de/montaže bistveno bolj pomembna od cene materiala, ko je ta na mizi.
Cena crkotja nekje na oddaljenem mestu in povezani servis pa prevlada obe prejšnji.
Posredni stroški pa njega.
BlaY0 ::
Če bi to jaz delal, se ne bi zajebaval s karticami. Na mikrokonktroler bi počil NAND FLASH čip v zahtevani kakovosti direktno na isti PCB preko ONFI vmesnika.
Jaz isto. Ampak zdaj imajo v bistu full hud PC, ki pa je zelo rigiden.
Ja folk se ne zaveda, da bo imel full enih stroškov s supportom, ker je za ceno hitre implementacije uvedel do onemoglosti abstrahiran sistem. Na začetku se sliši lepo 100 EUR daš za eno sondo, v primeru namenske sonde pa bi bila ta cena 500 EUR... ja potem se moraš pa 2x na mesec furat ne vem kam pa po snegu gazit 3 kilometre ;)
mojca ::
Kako pa akumulatorji prenašajo strele? Delajo še vedno b.p.?
Z akumulatorji doslej ni bilo nobenih težav, vsaj ne da bi vedela. Skurilo je sicer že več industrijskih napajalnikov enega tipa z doživljensko garancijo (napajalnikom drugega tipa pa ne more nič do živega, razen mravelj), akumulatorjem pa ni nič. Nazadnje sem dva akumulatorja poslala v garancijsko menjavo. Pri enem je bila skurjena (navadna avtomobilska) varovalka, pri drugem pa ne. Morda so te varovalke prepočasne?
Prenapetostna zaščita pomeni, da je treba dati na vse, kar po bakru pride v mašino (el. napajanje, POTS linij nimate) na kvalitetno prenapetostno zaščito (kjer bodo varovalke odklopile prenapetost - vendar ne vem, če ni tu z varovalko zaščiten samo fazni vodnik??), še boljše pa na on-line UPS, kjer UPS gladi vse špice, oprema pa se napaja izključno iz akumulatorja v njem. Po regelcih bi morala v primeru večje prenapetosti najprej odpovedati ali prenapetostna zaščita oziroma UPS.
Kaj pomeni kvalitetna prenapetostna zaščita? Kakšno zaščito konkretno bi montirali vi? Na antenah (GPRS, GPS) res ni absolutno nobene zaščite in to je potrebno popraviti. Na 12V linijah so neke varovalke (ne vem še, kakšne in kje). Morda so prepočasne, morda predaleč od elektronike. Pred kratkim sem bila prepričana, da je med strelo skurilo eno od dragih naprav, pa je k sreči razneslo samo varovalko (neko specialno, na katero sem čakala tri tedne).
UPSe moram malo preučiti, da vidim, kako so narejeni. Obstoječa oprema se že sedaj "napaja iz akumulatorja", ampak problem je, da so skoraj gotovo na isti točki na akumulatorju priključeni napajalnik/polnilec, baterijski konektor in naprava. Če se sfuzla napajalniku, je to verjetno dovolj, da gre spike naprej po DC žici. Ampak tudi DC napajanje gre verjetno po dovolj dolgih žicah, da se lahko v primeru udara strele nekje v bližini samo na njih inducira dovolj napetosti, da uniči opremo. Obstaja sploh kakšen tip vezave, ki bi omilil slednje (farradayeva kletka z bakreno pletenico okrog dvožilnega kabla, vijačno prepletena plus in ničla, ...)?
mislim, da bi že dober Belkin rešil težavo s stelami.
O katerem Belkinu je govora? (Ne govorim o PC-jih, ampak to, da je njihova oprema kao zaščitena pred udari strele, so trdili tudi proizvajalci opreme, pa ni držalo.)
Zgodovina sprememb…
- spremenila: mojca ()
mojca ::
@mojca: Glede na to da ste nabavili Alix-e... zakaj niste pri PC Engines nabavili tudi SLC CF kartic? Kar se tiče arhitekture... zadevo je potrebno narediti tako, kot so narejeni routerji. V končni fazi tisti router na katerega imaš povezane Alix-e nima notri nič drugega kot SLC NAND Flash. Glede na to, da je tehnologija podobna ma zanima, kolikokrat ste menjali router?
Prvič: ne vem, zakaj, ker me ni bilo zraven. Drugič: ni se kupovalo direkt od Alix-a, pa tudi če bi se, se takrat ni vedelo, kakšni problemi bodo. Tretjič: za SLC slišim prvič. Hvala za "keyword". Zdaj ko gledam, jih je zares še kar težko dobiti. Vidim sicer neke Transcend kartice (ki pa so v primerjavi z ostalimi skoraj sumljivo poceni, če gre res za tako veliko razliko v kvaliteti). Torej naj bi bil npr. Transcend SLC (prvi, ki ga najdem) bolj zanesljiv od SanDisk Extreme?
Router je bil menjan "samo" enkrat, vendar zaradi udara strele v bližini (najverjetneje je prišel udarec po nezavarovani GSM/GPRS anteni) in je "spotoma" skurilo še en Alix od treh. Drugih problemov z njim ni bilo.
misek ::
Vi potrebujete eno konkretno postavitev in zaščito teh naprav. Še posebej če so res tako drage.
Kontaktirajte kakšnega radioamaterja, ki skrbi za naprave na oddajnih točkah. Ti imajo kar precej izkušenj s takšnimi zadevami.
Kontaktirajte kakšnega radioamaterja, ki skrbi za naprave na oddajnih točkah. Ti imajo kar precej izkušenj s takšnimi zadevami.
mojca ::
Sicer je res, da je doslej škodo vedno krila zavarovalnica, ampak nedvomno bomo potrebovali profesionalno pomoč nekoga, ki se spozna na "ekstremne razmere". Se priporočam za kontakte na ZS, če veste za koga, bom pa še sama poiskala. Z enim soforumašem sem že na zvezi.
(Nenazadnje tudi TV oddajniki kar delujejo, pa so verjetno višji in bolj izpostavljeni ...)
(Nenazadnje tudi TV oddajniki kar delujejo, pa so verjetno višji in bolj izpostavljeni ...)
mojca ::
Preverila sem eno od okvarjenih kartic. Filesystem ni pokvarjen in read-only linux particija se zdi ok. Na particiji, kjer so se zapisovali podatki, pa ena od mnogih datotek ni berljiva (vsi ostali podatki razen ene datoteke so brez tezav dostopni), medtem ko badblocks natanko za vsak veckratnik stevila 64 pove, da je blok 64*n okvarjen (po 0.11% sem ustavila diagnostiko):
> sudo badblocks -nvs /dev/sdc2 Checking for bad blocks in non-destructive read-write mode From block 0 to 2098175 Checking for bad blocks (non-destructive read-write test) Testing with random pattern: badblocks: Input/output error during test data write, block 0 ... 63 badblocks: Input/output error during test data write, block 64 64 ... badblocks: Input/output error during test data write, block 128 ... badblocks: Input/output error during test data write, block 192 ... badblocks: Input/output error during test data write, block 256 ... (verjetno do konca kartice tako)
BlaY0 ::
Brane22 ::
Nisem zuiher, da bi šlo do konca. FLASH ima velikost bloka za vpis ponavadi 4K, blik za brisanje je pa veliko večji, ponavadi 2M ali kaj podobnega.
Če je filesystem veliko šaril po isti skupini blokov, je možno da je zjebal cel erase blok do te mere,d a ga je vdelani mikrokontroler ensotavno odpisal. In če ta poskuša doseči poceni wear-leveling tako ,da interlieva erase-bloke 1:64, potem je ta posledica verjetna.
Ker pa je v enem erase bloku nekako n*512 write blokov, je verjetno,d a bi se ta seznam sčasoma ustavil, če je prizadeto majhno število erase blokov. usti stvar da pride do konca ali pa vsaj poglej, če se badbloki nadaljujejo do konca na ta način ali pa se nehajo po nekem času.
Če se nadaljujejo do konca, to kaže na neko napako v kontrolerju ali v logiki flasha. Če se ne, to kaže na wear&tear death erase bloka.
Poglej še ostale kartice in predvsem ujemanje napak. Ni nujno da so vse crknile na isti način. Lahko da jih ubije wear&tear, če jih prej ne zjebe udar strele.
Jaz bi:
- se zazrl v prioriteto reševanja podproblemov očitno kompleksnega celotnega problema.
- če kartica crkne na ta način, je to nek _hint_, da crkne zaradi wear&teara, ne zaradi strele.
Če je wear&tear pomemben faktor, bi pogledal:
1. če lahko spremeniš tip filesystema in če ti krenel dovoljuje nilfs2 ali f2fs, bi se odločil za to, najraje f2fs. Pri inicializaciji bi pogledal, če je kje kaka opcija, s katero obvestim utility o velikosti vpisnega bloka, da se ne bo igral s 512-bytnimi sektorji na mediju, kjer je ta 4K ( in bo tako vsak write vpis v bistvu read-modify-write in bo tako dodatno kuril celice, ker bo za vpis enega 4K bloka le-tega vpisal 8x, vsakič po pol kilobajta).
2. če mi sprememba filesystema ni dovoljena, lahko ap reinicializiram extX na particiji, bi pogledal z tune2fs, če ima pravilno nastavljeno velikost bloka vpisa. Če je nima, bi stvar reformatiral. Če se da, bi uporabil ext2, ker za tako majhno število fajlov journal samo komplicia zadeve in povzroča dodaten wear&tear brez potrebe.
3. vsekakor bi pazil, kaj fs počne po particiji. extX je imel navado, da je za VSAK dostop do nekega fajla spremenil njegov access time atribut in je tako tudi med branjem vpisoval. In kar je še najslabše, vpisoval je vedno v iste sektorje. Torej je v primeru extX noatime opcija _nujna_ , nisem pa ziher če ni zastarela in če ne obstaja kakšna nova zamenjava.
4. Če nisem uspel spremeniti filesystema, bi pogledal, če lahko spremenim način vpisa.
Najbolje bi bilo, če lahko odprem celo particijo kot file, v njem poiščem zadnji vpis in vpisujem cirkularno.
Če tega iz nekega vzroka ne morem, lahko naredim isto na filesystemu. Odprem en fajl, ki zaseda večino filesystema in ponovim vajo.
AD4:
Tu pomaga, če ta fajl v celoti vpišeš že na začetku. To pa zaradi tega, da filesystem že rezervira prostor in zapolni potrebne inode in da vsako poznejše prepisovanje podatkov prizadane le sektorje s podatki, ne pa metadate v strukturi filesystema.
Če je filesystem veliko šaril po isti skupini blokov, je možno da je zjebal cel erase blok do te mere,d a ga je vdelani mikrokontroler ensotavno odpisal. In če ta poskuša doseči poceni wear-leveling tako ,da interlieva erase-bloke 1:64, potem je ta posledica verjetna.
Ker pa je v enem erase bloku nekako n*512 write blokov, je verjetno,d a bi se ta seznam sčasoma ustavil, če je prizadeto majhno število erase blokov. usti stvar da pride do konca ali pa vsaj poglej, če se badbloki nadaljujejo do konca na ta način ali pa se nehajo po nekem času.
Če se nadaljujejo do konca, to kaže na neko napako v kontrolerju ali v logiki flasha. Če se ne, to kaže na wear&tear death erase bloka.
Poglej še ostale kartice in predvsem ujemanje napak. Ni nujno da so vse crknile na isti način. Lahko da jih ubije wear&tear, če jih prej ne zjebe udar strele.
Jaz bi:
- se zazrl v prioriteto reševanja podproblemov očitno kompleksnega celotnega problema.
- če kartica crkne na ta način, je to nek _hint_, da crkne zaradi wear&teara, ne zaradi strele.
Če je wear&tear pomemben faktor, bi pogledal:
1. če lahko spremeniš tip filesystema in če ti krenel dovoljuje nilfs2 ali f2fs, bi se odločil za to, najraje f2fs. Pri inicializaciji bi pogledal, če je kje kaka opcija, s katero obvestim utility o velikosti vpisnega bloka, da se ne bo igral s 512-bytnimi sektorji na mediju, kjer je ta 4K ( in bo tako vsak write vpis v bistvu read-modify-write in bo tako dodatno kuril celice, ker bo za vpis enega 4K bloka le-tega vpisal 8x, vsakič po pol kilobajta).
2. če mi sprememba filesystema ni dovoljena, lahko ap reinicializiram extX na particiji, bi pogledal z tune2fs, če ima pravilno nastavljeno velikost bloka vpisa. Če je nima, bi stvar reformatiral. Če se da, bi uporabil ext2, ker za tako majhno število fajlov journal samo komplicia zadeve in povzroča dodaten wear&tear brez potrebe.
3. vsekakor bi pazil, kaj fs počne po particiji. extX je imel navado, da je za VSAK dostop do nekega fajla spremenil njegov access time atribut in je tako tudi med branjem vpisoval. In kar je še najslabše, vpisoval je vedno v iste sektorje. Torej je v primeru extX noatime opcija _nujna_ , nisem pa ziher če ni zastarela in če ne obstaja kakšna nova zamenjava.
4. Če nisem uspel spremeniti filesystema, bi pogledal, če lahko spremenim način vpisa.
Najbolje bi bilo, če lahko odprem celo particijo kot file, v njem poiščem zadnji vpis in vpisujem cirkularno.
Če tega iz nekega vzroka ne morem, lahko naredim isto na filesystemu. Odprem en fajl, ki zaseda večino filesystema in ponovim vajo.
AD4:
Tu pomaga, če ta fajl v celoti vpišeš že na začetku. To pa zaradi tega, da filesystem že rezervira prostor in zapolni potrebne inode in da vsako poznejše prepisovanje podatkov prizadane le sektorje s podatki, ne pa metadate v strukturi filesystema.
Zgodovina sprememb…
- spremenilo: Brane22 ()
Brane22 ::
Aja, še to.
Za štos bi na mizi sformatiral neko tako kartico, počil gor nekaj fajlov in potem pogledal, kam točno "padejo" podatki fajlov. Če fajl pade na write boundary, bi vedel da je zame optimalno da ga vpisujem v korakih te velikosti ali večkratniki, ker bodo sicer potrebni read-modify-write cikli za vsak vpis.
Poleg tega, ko "naredim krog" bi pomagalo, če reinicializiram na začeku za n*erase blokov, sicer se bo vdelani mikrokrmilnik moral iti gimnastiko za vsako vpis. Če je celoten erase blok prazen in vpisujem vanj, ni problema.
Če pa so na njem že podatki in jaz vpisujem nekaj novega v nek sektor, se bo mikrokrmilnik moral nekako znajti, saj mora zbrisati cel erase blok, misli pa da 99% preostalih podatkov v njem rabim. KAr pomeni, da bo vsak moj vpis povzročil plaz pisanj in brisanj po skritih plonk ceglcih v FLASHu.
Tako da bi bilo zdravo že takoj na začetku imet nekaj erase blokov inicializiranih, da kontrolerju ni treba delno eraseat. Je pa kritično vedet, kaj to pomeni- ali so zanj prazne same enke ali same ničle.
Na navadnem disku je prazen sektor poln ničel. Pri navadni FLASH celici je prazna celica polna enk.
Kako so se pa odločili pri teh napravah, ne vem na pamet. Bi blo pa to zdravo vedet, sa j bi napačna mplementacija samo poslabšala problem.
Za štos bi na mizi sformatiral neko tako kartico, počil gor nekaj fajlov in potem pogledal, kam točno "padejo" podatki fajlov. Če fajl pade na write boundary, bi vedel da je zame optimalno da ga vpisujem v korakih te velikosti ali večkratniki, ker bodo sicer potrebni read-modify-write cikli za vsak vpis.
Poleg tega, ko "naredim krog" bi pomagalo, če reinicializiram na začeku za n*erase blokov, sicer se bo vdelani mikrokrmilnik moral iti gimnastiko za vsako vpis. Če je celoten erase blok prazen in vpisujem vanj, ni problema.
Če pa so na njem že podatki in jaz vpisujem nekaj novega v nek sektor, se bo mikrokrmilnik moral nekako znajti, saj mora zbrisati cel erase blok, misli pa da 99% preostalih podatkov v njem rabim. KAr pomeni, da bo vsak moj vpis povzročil plaz pisanj in brisanj po skritih plonk ceglcih v FLASHu.
Tako da bi bilo zdravo že takoj na začetku imet nekaj erase blokov inicializiranih, da kontrolerju ni treba delno eraseat. Je pa kritično vedet, kaj to pomeni- ali so zanj prazne same enke ali same ničle.
Na navadnem disku je prazen sektor poln ničel. Pri navadni FLASH celici je prazna celica polna enk.
Kako so se pa odločili pri teh napravah, ne vem na pamet. Bi blo pa to zdravo vedet, sa j bi napačna mplementacija samo poslabšala problem.
Brane22 ::
Aja, pa ko brišeš FLASH, ga je fajn zbrisat tako, da driver to rpepozna kot izbris, ne pa kot N zaporednih vpisov.
Narava Linuxovega IO subsistema in VFS stacka je taka, da dela coalescing writes in prepozna take stvari, samo dobro je preverit, kaj dejanjsko se dogaja.
Narava Linuxovega IO subsistema in VFS stacka je taka, da dela coalescing writes in prepozna take stvari, samo dobro je preverit, kaj dejanjsko se dogaja.
Brane22 ::
Zdaj sem šel gledat mount opcije in videt je, da bi se ob noatime prilegla še nodiratime.
Nisem pa našel opcije, ki bi preprečila update write timea, kar je slabo, glede na to, da bo večina dostopov takih.
Nisem pa našel opcije, ki bi preprečila update write timea, kar je slabo, glede na to, da bo večina dostopov takih.
hojnikb ::
Če je tolk težav okol teh kartic, si pa umisliš NOR based zadevo, ki teh težav nima :)
#brezpodpisa
Brane22 ::
Kako jih nima ? Če vpišem 100.000x neko zadevo v NOR celico, bo ta po neki magiji zdržala, kar NAND ne bi ?
Saj gre za enake celice, le infrastruktura, v katero so zložene, je drugačna.
Saj gre za enake celice, le infrastruktura, v katero so zložene, je drugačna.
BlaY0 ::
Zdaj sem šel gledat mount opcije in videt je, da bi se ob noatime prilegla še nodiratime.
Nisem pa našel opcije, ki bi preprečila update write timea, kar je slabo, glede na to, da bo večina dostopov takih.
Noatime privzeto naredi tudi nodiratime tako da ni potrebno eksplicitno navajati še nodiratime. Delay write-a oziroma sync pa se dela z opcijo commit=[sekunde].
Zgodovina sprememb…
- spremenilo: BlaY0 ()
hojnikb ::
Kako jih nima ? Če vpišem 100.000x neko zadevo v NOR celico, bo ta po neki magiji zdržala, kar NAND ne bi ?
Saj gre za enake celice, le infrastruktura, v katero so zložene, je drugačna.
ja, ampak pri nor nimaš težav z velikimi bloki.. torej manjši wear, sploh če je pri NAND stvar slabo zastavljena...
#brezpodpisa
Brane22 ::
Ne ta delay write. To je na nivoju ext2/3/4.
Rabiš tistega na nivoju IO elevatorja, to je par nivojev nižje.
Rabiš tistega na nivoju IO elevatorja, to je par nivojev nižje.
Brane22 ::
ja, ampak pri nor nimaš težav z velikimi bloki.. torej manjši wear, sploh če je pri NAND stvar slabo zastavljena...
Ti v bistvu ne razumeš problema. Tle niso glavna težava veliki bloki, ker tu ne gre za klasično aplikacijo ampak log file. Glavna operacija je tu append. Večji ali manjši write & erase bloki niso problem, dokler se tega zavedaš in to obideš.
Problem je maljon mplicitnih writeov, ki jih filesystem dela tudi ko bereš. Če ti zadanejo vedno isto lokacijo in se stalno ponavljajo, ti bodo zjebali FLASH.
barrier
ne bariere. To je še vedno drugje.
Rabiš nekaj, kar bo:
1. IO system znal zložit v en sekvenčen write
2. za kar bo assess driver znal reči "Hej, tele vpise si lahko pokrajšam z eraseom namesto erase/writeom".
Če se ne zgodi OBOJE, ni učinka.
Zgodovina sprememb…
- spremenilo: Brane22 ()
hojnikb ::
ja, ampak pri nor nimaš težav z velikimi bloki.. torej manjši wear, sploh če je pri NAND stvar slabo zastavljena...
Ti v bistvu ne razumeš problema. Tle niso glavna težava veliki bloki, ker tu ne gre za klasično aplikacijo ampak log file. Glavna operacija je tu append. Večji ali manjši write & erase bloki niso problem, dokler se tega zavedaš in to obideš.
Problem je maljon mplicitnih writeov, ki jih filesystem dela tudi ko bereš. Če ti zadanejo vedno isto lokacijo in se stalno ponavljajo, ti bodo zjebali FLASH.
zato pa maš wearlevelling na ravni kontrolerja.. Če pa ta slabo deluje, pa keširaš spremembe logov v nek ram cache, ko dosežejo enkrat neko kritično maso, jih pa dumpaš na flash.. jasno pa more bit to seveda tak zastavljen, da ob izgubi štroma ne gre preveč meritev v k*rac..
#brezpodpisa
Brane22 ::
zato pa maš wearlevelling na ravni kontrolerja.. Če pa ta slabo deluje, pa keširaš spremembe logov v nek ram cache, ko dosežejo enkrat neko kritično maso, jih pa dumpaš na flash.. jasno pa more bit to seveda tak zastavljen, da ob izgubi štroma ne gre preveč meritev v k*rac..
Tist kontroler v elcheapo kartici je vreden ene pol kurca, največkrat niti toliko. Ni se pametno zanašat nanj, sploh če ti ni treba.
Glavni CPU ima dobesedno mnogo tisočkrat več konjskih moči in pomnilnika da bi se ubadal s tem, kot tista patetična $0.1 vredna zadeva znotraj kartice.
hojnikb ::
In potem pridemo nazaj do NOR flasha, kjer maš TI kontrolo, v kiro celico gre katera sprememba..
Oz. kupiš takšno kartico ki ima spodobne krmilnik z statičnim in dinamičnim wearlevellingom (verjetno je to misijan nemogoče za CF)
Oz. kupiš takšno kartico ki ima spodobne krmilnik z statičnim in dinamičnim wearlevellingom (verjetno je to misijan nemogoče za CF)
#brezpodpisa
Zgodovina sprememb…
- spremenil: hojnikb ()
Brane22 ::
Se ti zavedaš, da nimaš pojma o čem govoriš ?
Zakaj točno naj pri NANDu te kontrole ne bi imel ?
ker se podatki vpisujejo v NAND čip preko nekega posredniškega angela in posebne molitve ?
Zakaj točno naj pri NANDu te kontrole ne bi imel ?
ker se podatki vpisujejo v NAND čip preko nekega posredniškega angela in posebne molitve ?
hojnikb ::
Se ti zavedaš, da nimaš pojma o čem govoriš ?
Zakaj točno naj pri NANDu te kontrole ne bi imel ?
ker se podatki vpisujejo v NAND čip preko nekega posredniškega angela in posebne molitve ?
nesramen pa spet ni treba bit.
In ja, ta posredniški "angle" je kontroler.
Seveda lahko imaš direktno kontrolo pr NANDU na BLOK nivoju.. ampak če je vsaka sprememba 100x manjša od bloka in vsako zapišeš v BLOK... no ti je jasno kam to gre.. razn če seveda keširaš in zapišeš, ko se enkrat nabere dost podatkov za blok al pa page in dumpaš za vsak na drugo lokacijo (če seveda maš to kontrolo).
#brezpodpisa
Zgodovina sprememb…
- spremenil: hojnikb ()
Brane22 ::
Seveda lahko imaš direktno kontrolo pr NANDU na BLOK nivoju.. ampak če je vsaka sprememba 100x manjša od bloka in vsako zapišeš v BLOK... no ti je jasno kam to gre..
V bistvu mi ni.
Prvič, v mnoge FLASH pomnilnike ti lahko veselo vpisuješ poljubno majhne podatke, ne glede na blok.
Ne da se mi it zdaj preverjat NAND čipovje samo zaradi verbalnih duelov, a sumim, da je tudi tam tako.
Recimo da je najmanjši vpisljivi blok 4K. In da čip zna vpisati ničle, enke so zanj eraseano stanje.
Kaj narediš, če bi rad vpisal en byte, recimo $aa ? Nič posebnega. Pripraviš v RAM 4k blok praznih $ff byteov, počiš svoj byte kjer bi rad in vpišeš cel blok. In kaj, ko bi rad zapisal naslednji, recimo $bb byte ?
Nič, posebnega. Prebereš cel 4k blok, "pohodiš" obstoječi byte s svojim $bb tako, in vpišeš cel blok nazaj.
Če so spremembe take, da samo enke spreminjaš v ničle, ne bi smelo biti problema.
Drugič, če predpostavimo da prej opisani način ne gre, še vedno ni frke. Pač vpisuješ 4k bloke, ko se nabere zadosti podatkeov, kar glede na aplikacije ne bi smelo biti nikakršen problem.
hojnikb ::
Drugič, če predpostavimo da prej opisani način ne gre, še vedno ni frke. Pač vpisuješ 4k bloke, ko se nabere zadosti podatkeov, kar glede na aplikacije ne bi smelo biti nikakršen problem.
če ta opcija obstaja, potem sploh ni nobenih težav. Seveda, če vedno prepišeš drug fizični blok, kjub temu, da je ta blok na FS nivoju vedno na isti "lokaciji" (spremembe v logih).
#brezpodpisa
Zgodovina sprememb…
- spremenil: hojnikb ()
mojca ::
Hoj, glede na to, da pri sebi nimam čitalca kartic, bom morala še kak teden počakati na nadaljnje eksperimente. Vraga! Zdaj ste me toliko sprovocirali, da nisem želela kartic poslati nazaj, da se bom lahko še nekaj časa igrala z njimi in pognala malenkost več diagnostike. Sicer žal nimam pokvarjenih kartic v množini. Od petih, kolikor jih še imam, je ena očitno popolnoma uničena (diagnostike ne morem pognati, ker ji linux sploh ne dodeli /dev/sd(nekaj) oznake), na treh karticah ni zaznati težav (moram pa diagnostiko speljati do konca), "ravno prav" defektna pa je le ena. Ostale so kot kaže romale v koš ali kamorkoli že - dobila jih verjetno ne bom.
Da ne bo nesporazuma: stvar še vedno deluje v "proof of concept" načinu in če ne pomisliš na to, ciklanje bajtov pač ni prva stvar, na optimizacijo katere bi človek pomislil, ko moraš poskrbeti še za tisoč težjih problemov, začenši z zoprnimi sosedi. Če ne bi nikogar vprašala, bi bil tudi moj naiven pristop ta, da bi na kartico namestila debian v read-write načinu na ext4 particijo in vsako sekundo na kartico vpisala par številk, loge pa seveda pustila.
Ja, nekaj kartic je šlo morda k vragu zaradi strele, ampak zdaj mi ni težko pojasniti wear-and-tear scenarija. Če vsako sekundo poženeš program, ki se mora najprej prebrati z diska, prebrati podatke ter nato v sql bazo vpisati eno vrstico in sistem deluje tako, da pri vsakem vpisu spremeni en in isti byte (ali bit) na kartici, je skuriti bit, ki je teoretično prepisljiv le deset ali stotisočkrat, mačji kašelj. En dan in zbogom kartica. (Oziroma zbogom bit ... ampak takoj ko so se začele pojavljati kakršnekoli napake pri branju ali pisanju, so kartice menjali.) Pri tovrstni "programerski" praksi prepisovanja istega bita mi tudi "military grade" kartica ne more pomagati.
Kljub vsemu sem se zdaj naučila, da naj bi nekatere kartice (SLC) prenesle vsaj 10x več vpisov kot običajne (ne vem sicer, ali to pomeni, da je 1 GB SLC kartica ekvivalentna 10 GB MLC, če vpisuješ na pameten način), da imajo boljše kartice kondenzatorček ob napajanju in so tako manj odporne na nenadne izpade napetosti, da je na nekaterih karticah deklarirano delovanje do -40 stopinj (na drugih ne) ipd. Da je pomembno izključiti vsa nepotrebna logiranja (nekateri logi utegnejo biti kljub vsemu uporabni), da je potrebno formatirati v tak filesystem, ki ne bo prepisoval enih in istih celic (če že ne low-level implementacija brez file-systema - ampak to bi preskočila), da je mogoče smotrno nekaj časa podatke hraniti v spominu namesto vsako sekundo vpisati na disk itd. itd. itd. Vse informacije s foruma moram sicer še premleti, da bom povsem razumela, ampak mislim, da lahko s temi podatki karticam vsaj 10x, če ne 100x podaljšam življensko dobo
, kar je sprejemljivo, medtem pa razmislim o tem, kako optimizirati setup (menjati Alixe za mikrokontroler ipd.), lahko tudi z zunanjo pomočjo.
Hvala vsem, predvsem Branetu. Poročam čez kakšen teden, ko bom zopet eksperimentirala s pol-okvajenimi-karticami.
Da ne bo nesporazuma: stvar še vedno deluje v "proof of concept" načinu in če ne pomisliš na to, ciklanje bajtov pač ni prva stvar, na optimizacijo katere bi človek pomislil, ko moraš poskrbeti še za tisoč težjih problemov, začenši z zoprnimi sosedi. Če ne bi nikogar vprašala, bi bil tudi moj naiven pristop ta, da bi na kartico namestila debian v read-write načinu na ext4 particijo in vsako sekundo na kartico vpisala par številk, loge pa seveda pustila.
Ja, nekaj kartic je šlo morda k vragu zaradi strele, ampak zdaj mi ni težko pojasniti wear-and-tear scenarija. Če vsako sekundo poženeš program, ki se mora najprej prebrati z diska, prebrati podatke ter nato v sql bazo vpisati eno vrstico in sistem deluje tako, da pri vsakem vpisu spremeni en in isti byte (ali bit) na kartici, je skuriti bit, ki je teoretično prepisljiv le deset ali stotisočkrat, mačji kašelj. En dan in zbogom kartica. (Oziroma zbogom bit ... ampak takoj ko so se začele pojavljati kakršnekoli napake pri branju ali pisanju, so kartice menjali.) Pri tovrstni "programerski" praksi prepisovanja istega bita mi tudi "military grade" kartica ne more pomagati.
Kljub vsemu sem se zdaj naučila, da naj bi nekatere kartice (SLC) prenesle vsaj 10x več vpisov kot običajne (ne vem sicer, ali to pomeni, da je 1 GB SLC kartica ekvivalentna 10 GB MLC, če vpisuješ na pameten način), da imajo boljše kartice kondenzatorček ob napajanju in so tako manj odporne na nenadne izpade napetosti, da je na nekaterih karticah deklarirano delovanje do -40 stopinj (na drugih ne) ipd. Da je pomembno izključiti vsa nepotrebna logiranja (nekateri logi utegnejo biti kljub vsemu uporabni), da je potrebno formatirati v tak filesystem, ki ne bo prepisoval enih in istih celic (če že ne low-level implementacija brez file-systema - ampak to bi preskočila), da je mogoče smotrno nekaj časa podatke hraniti v spominu namesto vsako sekundo vpisati na disk itd. itd. itd. Vse informacije s foruma moram sicer še premleti, da bom povsem razumela, ampak mislim, da lahko s temi podatki karticam vsaj 10x, če ne 100x podaljšam življensko dobo
, kar je sprejemljivo, medtem pa razmislim o tem, kako optimizirati setup (menjati Alixe za mikrokontroler ipd.), lahko tudi z zunanjo pomočjo.Hvala vsem, predvsem Branetu. Poročam čez kakšen teden, ko bom zopet eksperimentirala s pol-okvajenimi-karticami.
jernejl ::
Če vsako sekundo poženeš program, ki se mora najprej prebrati z diska, prebrati podatke ter nato v sql bazo vpisati eno vrstico in sistem deluje tako, da pri vsakem vpisu spremeni en in isti byte (ali bit) na kartici, je skuriti bit, ki je teoretično prepisljiv le deset ali stotisočkrat, mačji kašelj.
Kartice imajo v svojem flash krmilniku implementirane wear leveling algoritme. Kakšni so ti algoritmi, ni javno znano.
Običajno obstajata dva načina. Gre za to, da se pri vsakem pisanju na kartico - četudi gre za vpis na isto logično lokacijo - podatki zapišejo na drugo fizično lokacijo. Seveda to deluje na nivoju blokov - kar pomeni, da če zapišemo samo 1 bajt podatkov, se na kartico zapiše celoten blok (obrabo celic se tako lahko zmanjša na tak način, da se ne zapisuje vsaka majhna sprememba posebej, ampak se shranjujejo večje količine podatkov naenkrat).
Drugi algoritem pa meri obrabo (število ciklov) posameznih blokov in ko je razmerje med maksimalnim in minimalnim dovolj visoko, zamenja podatke posameznih blokov. Na tak način tudi tisti podatki, ki se nikoli ne spreminjajo, lahko spreminjajo fizično lokacijo.
Ukvarjati se z nekimi hudimi algoritmi za preprečevanje izrabe celic zato niti ni smiselno.
Dynamic wear leveling
The first type of wear leveling is called dynamic wear leveling and it uses a map to link Logical Block Addresses (LBAs) from the OS to the physical Flash memory. Each time the OS writes replacement data, the map is updated so the original physical block is marked as invalid data, and a new block is linked to that map entry. Each time a block of data is re-written to the Flash memory it is written to a new location. However, blocks that never get replacement data sit with no additional wear on the Flash memory. The name comes from only the dynamic data being recycled. The drive may last longer than one with no wear leveling, but there are blocks still remaining as active that will go unused when the drive is no longer operable.[2][3]
Static wear leveling
The other type of wear leveling is called static wear leveling which also uses a map to link the LBA to physical memory addresses. Static wear leveling works the same as dynamic wear leveling except the static blocks that do not change are periodically moved so that these low usage cells are able to be used by other data. This rotational effect enables an SSD to operate until most of the blocks are near their end of life.[2][3] This is also sometimes referred to as global wear leveling, as the entire image is leveled.[citation needed]
vir: Wear leveling @ Wikipedia
Tukaj je neka dokumentacija Kingstona, ki tudi pove nekaj o wear levelingu (in pravi ravno to, da njihovi algoritmi skrbijo, da je število program/erase ciklov pri blokih na kartici enakomerno porazdeljeno): http://media.kingston.com/pdfs/FlashMem...
Tukaj je nek whitepaper od Sandiska, ki tudi govori o njihovih wear leveling algoritmih:
http://www.scribd.com/doc/7010332/SANDI...
Bolj kot wear-levelingu bi se jaz posvetil npr. motnjam napajanja. Ena varianta je nabaviti nek online UPS.
Druga varianta je zmanjšati količino zapisovanja na kartico. Namesto da se zapisuje vsaka meritev sproti, se jih lahko zapiše recimo 50 naenkrat. Kartica bo tako manj obremenjena z zapisovanjem in manj verjetno je, da bi prišlo do napake zaradi nihanja napetosti.
Tukaj recimo pišejo o tem, da power cycling nič kaj blagodejno ne vpliva na krmilnik v pomnilniški kartici:
http://digital.ni.com/public.nsf/allkb/...
http://www.pcengines.ch/cfwear.htm
mojca ::
Pa obstaja kakšen UPS, ki ti da konstantno enosmerno napetost (med 7 in 20 V)? Alix ima širok spekter dovoljene napetosti, ne vem pa, kakšno napetost dostavlja CF kartici v primeru nestabilne napetosti. Na njihovem linku je lepo pojasnjeno "How to kill CF cards", nič pa ne piše o tem, kako ninanje napetosti na vhodu vpliva na nihanje napetosti na kartici. Imajo skico vezja, pa jih ne znam brati.
Kar ad-hoc kupiti en UPS za trenutno postavitev aparatur bi se mi zdelo še kar čuden, ker se je problema potrebno lotiti celostno. Npr. trenutno je napajalnik vezan na 12 V akumulator s cca. 100 Ah. (Ideja je v tem, da bi moralo napajanje zdržati vsaj tri dni, če pride do izpada elektrike.) Ven želiš dobiti čim lepših 12 V. Kam postaviš UPS in kakšnega? Res je, da nimam pojma o elektro stroki, ampak bi rekla, da je bolje, če kdo, ki se na to malo bolj spozna, razmisli in doda nekaj zaščitnih komponent na primerna mesta (četudi rezervne dele za UPS in četudi je rešitev dražja od UPS-a). Če se motim in je kakšna dobra off-the-shelf možnost za zagotavljanje konstantne napetosti, me pa zanima.
Upoštevati je potrebno tudi, da se lahko na cca. 50 metrih žice z enosmerno napetostjo ob bližnjem udaru strele verjetno inducira dovolj napetosti, da je vseeno, kako idealen izvor napetosti imaš na drugi strani žice in opremo v vsakem primeru skuri.
En "strela za telebane" priročnik sem ravnokar našla tule: http://www.elektrospoji.si/uploads/menu...
Kar ad-hoc kupiti en UPS za trenutno postavitev aparatur bi se mi zdelo še kar čuden, ker se je problema potrebno lotiti celostno. Npr. trenutno je napajalnik vezan na 12 V akumulator s cca. 100 Ah. (Ideja je v tem, da bi moralo napajanje zdržati vsaj tri dni, če pride do izpada elektrike.) Ven želiš dobiti čim lepših 12 V. Kam postaviš UPS in kakšnega? Res je, da nimam pojma o elektro stroki, ampak bi rekla, da je bolje, če kdo, ki se na to malo bolj spozna, razmisli in doda nekaj zaščitnih komponent na primerna mesta (četudi rezervne dele za UPS in četudi je rešitev dražja od UPS-a). Če se motim in je kakšna dobra off-the-shelf možnost za zagotavljanje konstantne napetosti, me pa zanima.
Upoštevati je potrebno tudi, da se lahko na cca. 50 metrih žice z enosmerno napetostjo ob bližnjem udaru strele verjetno inducira dovolj napetosti, da je vseeno, kako idealen izvor napetosti imaš na drugi strani žice in opremo v vsakem primeru skuri.
En "strela za telebane" priročnik sem ravnokar našla tule: http://www.elektrospoji.si/uploads/menu...
Zgodovina sprememb…
- spremenila: mojca ()
Brane22 ::
@mojca:
Sem ti poslal mail. Tam sem se dotaknil tega in še marsičesa.
Kar se same špice v napajanju tiče, ne verjamem. Če bi prizadela flash, bi še kaj drugega.
Čeprav OTOH tem vdelanim napajalnikom, ki so kar na isti napravi na par cm2 tudi ne verjamem preveč.
Sem ti poslal mail. Tam sem se dotaknil tega in še marsičesa.
Kar se same špice v napajanju tiče, ne verjamem. Če bi prizadela flash, bi še kaj drugega.
Čeprav OTOH tem vdelanim napajalnikom, ki so kar na isti napravi na par cm2 tudi ne verjamem preveč.
Brane22 ::
Kar se same špice v napajanju tiče, ne verjamem. Če bi prizadela flash, bi še kaj drugega.
To ne pomeni, da tam špica ziher ni problem. Ali da ob kaki motnji ali streli ne more bit celo dsestruktivna še za kaj.
Samo da ni ravno verjetno, da pride špica skozi na tak način, da se sesuje CF kartica, vse ostalo pa je niti opazi ne.
mojca ::
Ce prav razumem log-e, se je badblocks po 14-ih urah zakljucil s temle:
Zakaj ni slo dalje, ne vem.
11.84% done, 14:19:31 elapsed. (2184/0/132640 errors)
Zakaj ni slo dalje, ne vem.
Grega_K ::
Temo sem le na hitro preletel; v kolikor je kdo že zastavil podobno vprašanje se opravičujem.
Zanima me, kaj točno merite?
Zanima me, kaj točno merite?
Lp
Zgodovina sprememb…
- spremenilo: Grega_K ()
jebiveter2 ::
In potem pridemo nazaj do NOR flasha, kjer maš TI kontrolo, v kiro celico gre katera sprememba..
Oz. kupiš takšno kartico ki ima spodobne krmilnik z statičnim in dinamičnim wearlevellingom (verjetno je to misijan nemogoče za CF)
V bistvu so kontrolerji že precej advanced.
Res nima moči še najbolj sklerotičnega atoma, samo v CF kartici, kjer je prostora veliko, si te zadeve že lahko privoščiš.
Mogoče bi bilo vredno preveriti, ali je kartica Ok s 5V napajalne napetosti, s katero jo določeni kontrolerji filajo, ali se počuti bolje na 3.3V.
Hoj, glede na to, da pri sebi nimam čitalca kartic, bom morala še kak teden počakati na nadaljnje eksperimente. Vraga! Zdaj ste me toliko sprovocirali, da nisem želela kartic poslati nazaj, da se bom lahko še nekaj časa igrala z njimi in pognala malenkost več diagnostike. Sicer žal nimam pokvarjenih kartic v množini. Od petih, kolikor jih še imam, je ena očitno popolnoma uničena (diagnostike ne morem pognati, ker ji linux sploh ne dodeli /dev/sd(nekaj) oznake), na treh karticah ni zaznati težav (moram pa diagnostiko speljati do konca), "ravno prav" defektna pa je le ena. Ostale so kot kaže romale v koš ali kamorkoli že - dobila jih verjetno ne bom.
Glede teh eksperimentov - bodi pozorna na temperaturo kartice. Določene napake se lahko začnejo pojavljati samo pri neki prehodni temperaturi, kar je višje in nižje, pa ne.
Zgodovina sprememb…
- spremenilo: jebiveter2 ()
jebiveter2 ::
Ce prav razumem log-e, se je badblocks po 14-ih urah zakljucil s temle:
11.84% done, 14:19:31 elapsed. (2184/0/132640 errors)
Zakaj ni slo dalje, ne vem.
Slow sectors.
Zatakne se, ker kontroler ne zna hendlat napake na tistem delu (ali pa bere s 1000 ponovitvami, če prvič ne uspe), če nastaviš da ga prekočiš za par MB, lahko napako določiš bolj natančno, kar ti bo dalo tudi Info, katera datoteka se nahaja na tistem mestu.
Preračunaj si 11.84% glede na velikost kartice in dobiš štartno velikost. Pri 8GB kartici je to ravno pri 1GB meji, kar znese nekje za najbolj osnoven sistem + navlako v obliki programov.
Na obstoječem sistemu bi bilo fajn pognati kakšen file monitor in spremljati količino zapisov in branj ter kaj se dejansko počne.
Prenos sistema v ram tu ne bo pomagal, saj to ni to, kar ti povzroča napake.
A imaš to slučajno kakšne VIA epia in podobne sisteme ? Da ni vzrok temu pomanjkanje rama in nato futranje page-file-a s bedarijami, kar bo ubilo vsako kartico.
Glede same kartice, probaj pognati rusko Victoria SW za HDD check. (Možno da je ta verzija prava http://www.softpedia.com/get/System/Har... ) in najdi slabe/počasne sektorje.
Potem poizkusi prebrati kaj se nahaja na tistem sektorju, kar ti bo dalo info o vrsti datoteke, verjetno lahko uporabiš tisto na pol delujočo kartico za tako diagnostiko, bo lažje.
Moje izkušnje s CF so v rangu - Try to avoid. Ni vredno uporabljati tako staro tehnologijo, neglede na namen.
Sam bi vse vrgel na en netbook, ki ima drugače HDD (Hitachi preferably) slot in ne SSD palčke. Te igračke stanejo danes drobiž, porabo pa imajo okoli 10W s vklopljenim ekranom, kar ni dosti večje od obstoječega sistema, s tem da lahko pri kitajcu kupiš baterijo, s katerim čas delovanja podaljšaš na 12+ ur
Opcija, če ti plata omogoča je, da premakneš kartico v PIO mode (če že v tem ni) in zbiješ mode iz 4 na 0, kar bo zneslo dosti manj bandwidtha za pisanje. S tem bi lahko malenkost 'raztegnila' življensko dobo kartice, samo osnovna težava še ostaja.
Glede na to, da GSM modem že imate, bi sam uporabil opcijo streamanja RAW podatkov preko omrežja na lokalen komp, če le teh podatkov ni preveč. To je precej bullet proof rešitev.
Zgodovina sprememb…
- spremenilo: jebiveter2 ()
misek ::
imam 200 MB svojih podatkov, ki se sproti generirajo in pošiljajo dalje (v resnici je ta številka bliže 2 MB/dan + logi in ostala "svinjarija"Če je uporabnih podatkov res samo nekaj MB je rešitev zapisovanje podatkov v ram disk. Pa po potrebi periodično zapisovanje nazaja na kartico. Torej bi bilo zapisovanja na kartico res minimalno. Sam sistem na kartico že sedaj NE zapisuje ničesar, saj loge zapisuje v tmpfs.
jebiveter2 ::
Sam sistem na kartico že sedaj NE zapisuje ničesar, saj loge zapisuje v tmpfs
To bi blo za preverit, moje izkušnje so drugačne.
misek ::
jebiveter2 je izjavil:
Voyage Linux ne piše po disku. To je ena od bistvenih prednosti te distribucije.Sam sistem na kartico že sedaj NE zapisuje ničesar, saj loge zapisuje v tmpfs
To bi blo za preverit, moje izkušnje so drugačne.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Totalen format - ne moreš nič dobiti nazajOddelek: Programska oprema | 5157 (3688) | Jupito |
| » | SSD diski uničujejo digitalne dokaze (strani: 1 2 )Oddelek: Novice / Zasebnost | 18937 (14159) | Jst |
| » | SSD diskOddelek: Strojna oprema | 1784 (1307) | RejZoR |
| » | Micron izboljšal vzdržljivost NAND-flasha (strani: 1 2 )Oddelek: Novice / Ostale najave | 7097 (6156) | Pyr0Beast |
| » | IBM testira 4 TB SSD tehnologijoOddelek: Novice / Diski | 4880 (3089) | BaRtMaN |