Garrett szerint az alkalmazás írók nagy része számára teljesen haszontalan oly módon fájlrendszert tervezni, amelynek értelmes felhasználása lehetetlen, még akkor is ha egyes esetekben ez a módszer a teljesítmény javulását is hozhatja.
"Kedves fájlrendszer írók - az alkalmazás-fejlesztők szeretnek sok apró fájlt írni, mert ez nagyon sok dolgot jelentősen egyszerűbbé tesz. Ez rendben van, mert a puszta fájlrendszer teljesítmény nincs magasan a tipikus alkalmazás-fejlesztő prioritási listáján. A válasz nem az, hogy "Oh, mindannyiótoknak sqlite-ot kellene használnotok". Ha csak az adatbázis alkalmazása az egyetlen hatékony módszer a fájlrendszeretek használatára, akkor az azt jelenti, hogy nem írtatok olyan fájlrendszert, amely hasznos a tipikus alkalmazás-fejlesztők számára, akik élvezettel tárolják a dolgokat inkább fájlokban, mint bináris blobokban [...] Ha azt szerettem volna, hogy az összes adatom oracle-ben legyen tárolva, akkor a kezdetektől fogva nem lenne szükségem kib.szott fájlrendszerre, nem?"
A teljes blogbejegyzés itt.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Hogy mennyire haszontalan az egy dolog, de abban igaza van (szerintem), hogy ha kerítést akarok festeni a fájlrendszeremmel (mint az emberek 90%-a), akkor nem érdekel, hogy mennyire gyorsan magozza a meggyet, ha cserében necces a festés.
- A hozzászóláshoz be kell jelentkezni
A való világban hány filerendszerrel lehet "kerítést festeni"?
- A hozzászóláshoz be kell jelentkezni
Képletesen értve. Azt ne mond, hogy komolyan elgondolkoztál... :) tipp: "Kerítés festés" alá helyettesítsd be a manapság leggyakrabban elvárt funkciók bármelyikét, "meggymagozás" alá pedig valami olyat ami teljesen új, Generation X feature, csak éppen nincs rá mindenkinek szüksége.
- A hozzászóláshoz be kell jelentkezni
Én a kerítés festés helyett azt helyettesítettem be, amin a szóbanforgó írásban és annak előzményeiben is problémáznak.
- A hozzászóláshoz be kell jelentkezni
Remek, pont ezt szerettem volna elérni elsőre is. :) Nem akartam megismételni az eddig xy db fórumon az unalomig átbeszélt f*sync-es vagy f*sync-telen probléma kivesézgetését (ami véleményem szerint kicsit talán túl is van már hipe-olva), csak szerettem volna jelezni, hogy egyetértek a hírben szereplő illető megjegyzéseivel.
- A hozzászóláshoz be kell jelentkezni
Ha olyan alkalmazás-fejlesztő lennék, aki megelégszik azzal, hogy az alkalmazása csak bizonyos filerendszereken illetve bizonyos beállítások mellett működik megbízhatóan, akkor én is egyetértenék vele.
- A hozzászóláshoz be kell jelentkezni
Fordítva is lehet nézni. Ha olyan fájlrendszer készítő vagy, aki megelégszik, hogy csak bizonyos alkalmazások esetén működik megbízhatóan. :-)
- A hozzászóláshoz be kell jelentkezni
Én is így értelmeztem, és ő mintha pont azt mondta volna, hogy ez nem elég.
- A hozzászóláshoz be kell jelentkezni
Mivel hosszú-hosszú évek óta gyakorlatilag csak "problémás" (posix) filerendszereink vannak, és ezek még hosszú-hosszú évekig velünk lesznek, szerintem nem lehet fordítva nézni.
- A hozzászóláshoz be kell jelentkezni
Ok, the az O_TRUNC-al nyomulsz, akkor ez elvileg barmikor megtortenhet amugy is, sot ha jol remlik POSIX dolgoknal is le van irva fs-sel kapcsolatban hogy vannak nem igazan definialt allapotok. Ha barmi cucc van ami ujrair egy file-t hogy van egy allapot, amikor a file merete nulla, hat akkor nem kell csodalkozni, hogy elvileg pont ott bedolve a dolog nem is marad belole semmi. Ez ellen tenyleg ugy kene vedekezni hogy elkerulni a nem definialt allapotokat (pl igen, temp file-ba letenni, aztan rename-elni a regire), vagy definiciot keresni arra, hogy mi legyen ilyen esetekben, hiszen ezt nyilvan minden fs "szerzo" ugy implementalja ahogy akarja, ha nincs ra szentiras, hogy ilyenkor mi tortenjen ...
- A hozzászóláshoz be kell jelentkezni
Világos. A lényeg viszont, hogy az alkalmazások alá kell fájlrendszer, és nem fordítva. Nem azt mondom, hogy ész nélkül kell fejleszteni, de semmit nem ér az esetleges sebesség, ha biztonságosabb nem használni. Tudom, hogy ez nem újdonság, de ezért használok még mindig ext3-at (valahogy nyugodtabban alszom tőle). Persze ha videót vágnék, akkor lehet, hogy pont erre (ext4) lenne szükségem, meg egy jó kis szünetmentesre.
- A hozzászóláshoz be kell jelentkezni
Szünetmentes mindig kell :)
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Na de mi van az X-et csonttá fagyasztó ismeretlen feature-től, ami a billentyűzetet is magával viszi és mivel nincs az adott gépen ssh szerver, csak a reset gomb segít? :)
- A hozzászóláshoz be kell jelentkezni
tápkábel? az is csatlakozik valahogy a tápba... :D
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
megvárod, amíg syncel? (kb. egy perc)
esetleg sysrq
- A hozzászóláshoz be kell jelentkezni
Igen, de honnan tudjam, hogy mikortól kell várni? Ha a házat nézem, akkor az látszik, hogy egy üresjáratban lévő desktop is használja a lemezt néhány másodpercenként, egy szerver meg főleg. Itt nem az a gond, hogy az általam szerkesztett dokumentum veszne el (erre elég kicsi az esély), hanem, hogy olyan konfigurációs és logfile-ok nullázódnak, amiket a rendszer az én közreműködésem nélkül ír felül tetszőleges időpontokban.
Egy szerveren ez ciki, de a mezei user sem örül, ha újraindításkor nem indul a gnome v ópenoffisz, mert az alkalmazás épp áramszünetkor írta ki a configfile-át.
- A hozzászóláshoz be kell jelentkezni
szerveren van ssh
kliensen pedig ha nem fut az x, akkor nehezen szokott futni az openoffice (ha másnem, xforwarddal, vagy vncvel, de az előbb azt mondtad, nincs ssh)
- A hozzászóláshoz be kell jelentkezni
Én ebben a nagy flame áradatban csak azt nem értem, hogy világosan látszik, hogy az alkalmazásfejlesztők azok akik ész nélkül fejlesztenek.
Elég egyértelmű, hogy ha valami kritikus, akkor arra fsync, ha meg vmi. "mennyiségi" adat, akkor nem kell rá fsync, mert nem gáz ha elveszik.
Az egyetlen, ami miatt néhány alkalmazásban semmire sincs fsync, az a fejlesztők trehánysága.
- A hozzászóláshoz be kell jelentkezni
Yup, nem lehet a biznisz intelligencs hiányosságait a filerendszerre kenni.
A 12megás vinyó cache-t se lehet a filerendszerre fogni.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Aha, csak az sqlite olyan I/O terhelést ad, hogy öröm nézni ahogy a gép "megáll" az iowait-ek miatt.
Lásd firefox3, liferea...
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
En kiprobaltam az sqlite3-t spamszuresre (egy halom tokent tarolva benne), de csak select-eket adva ra, es semmi gubanc nem volt vele*. Bar azt hallottam, hogy ~180 MB meret korul azert mar nem olyan gyors....
*: PRAGMA synchronous = OFF pragmat hasznalva
SPAMtelenul - POP3 spamszuro szolgaltatas
- A hozzászóláshoz be kell jelentkezni
A liferea* csinál olyat ~30 feed felett, hogy átlag 500-1500 kbyte/s read és 300-400 kbyte/s write "terhelést" okoz** miközben egy körülbelül 10MB méretű db-vel dolgozik, így körülbelül 2-4 perc míg elindul*** és betölti a feedeket, ezután jön a frissítésük :D
Az egész könyvtárát tmpfs-re rátolva a fenti művelet gyakorlatilag másodpercek alatt végbemegy.
*gnome-os rss reader
**Ezeket iotop-pal mértem.
***5400rpm laptop diszk
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Na végre :)
"If a million monkeys were typing on computers, one of them will eventually write a Java program.
The rest of them will write Perl programs."
- A hozzászóláshoz be kell jelentkezni
open(), write(), fsync(), close()
Tegnap mászkáltam a tv-csatornák között, véletlenül hallottam ezt:
Telefonálnak:
- Bólints, ha beleegyezel.
- Bólint.
- És most szólj, hogy bólintottál-e az előbb.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Az én olvasatomban egészen másutt van a probléma gyökere.
A filerendszerek hatékonyságnövelése már csak azon az áron megy, hogy akár 5-10 percig is "szakadék fölött" lebegnek az adataink, miközben már rég biztonságban hisszük őket. A kulcs az alkalmazásfejlesztők kezében van, csak ugye ez az elmúlt 40 évben nem jelentett problémát, a filerendszer fejlesztők meg nem tartottak egy általános figyelemfelhívási kampányt, hogy "paradigma váltásra lesz szükség az alkalmazások fejlesztésénél, azaz a fontos adatokat sync-elni kell". Ugyanis eddig nem volt ilyenre szükség lassacskán viszont egyes helyeken lesz. Igen, ezt is meg kell tanulni, hogy mikor melyik fileműveletnél kell meggyőződni arról, hogy valóban kiírta a rendszer az adathordozóra.
Ezzel semmi gond, mindig vannak új tanulnivalók, a gond csak ott van, hogy erről nem szólt senki, hogy ilyen banánhéjat csempésztek be a talpunk alá!
- A hozzászóláshoz be kell jelentkezni
[irónia]Dehát ha olvasod a kernel forráskódját, akkor egyből látszik. Nem is értem, hogy minden alkalmazásfejlesztő miért nem olvassa a kernel forráskódját, ha már egyszer arra a platformra fejleszt.[/irónia]
"If a million monkeys were typing on computers, one of them will eventually write a Java program.
The rest of them will write Perl programs."
- A hozzászóláshoz be kell jelentkezni
Az a banánhéj nem újkeletű, már réges régen ott van a talpunk alatt.
- A hozzászóláshoz be kell jelentkezni
Igen.
Asszinkronná változtatni egy függvényt ami addig nem az volt, felelőtlenség, mert az összes eddigi program működésére kihat.
A helyes megoldás az, hogy amely utasítások korábban szinkron módban futottak - azaz a program csak akkor lépett a következő utasításra, amikor az előző utasítás hatásai létrejöttek - azok így is maradjanak!
Ha megjelenik egy új funkció mint most: adott hatást asszinkron utasítással is kérhetek, akkor az ezzel járó függvények kapjanak új neveket!
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Az a függvény eddig is aszinkron volt.
- A hozzászóláshoz be kell jelentkezni
De most még aszinkronabb lett, mert eddig az garantált volt hogy újraíráskor a meglévő adatok nem vesznek el, mostantól meg ennek biztosítása eddig nem igényelt szinkronizációs lépést igényel.
Azaz eddig a felülírás szinkronizált volt addig a pontig, hogy a régi adatok kiírodnak, és csak az új adatok kiírása volt aszinkron.
- A hozzászóláshoz be kell jelentkezni
Eddig sem volt garantált!
- A hozzászóláshoz be kell jelentkezni
Eddig is igényelte a fontos adat.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
"korábban szinkron módban futottak"
O RLY?
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Melyik a fontos adat? Szerintem mind fontos. Akkor ezentúl mindig syncelni kell? Ha igen, akkor a filérendszer fejlesztőknek nem sikerült hatékonyabb rendszert tervezni.
Nem az számít, hogy nehéz volna az alkalmazásokban syncelni, hanem vagy fejlődés, hatékonyság, késleltetett allokálás meg effélék, vagy syncelés. Elég nevetséges, hogy a syncelést ajánlják. Ellentmond annak, amiért dolgoznak.
Amúgy túl van dimenzionálva a probléma.
A Micimackóban Bagoly házán van egy csengő és egy kopogtató. Az egyiken a felirat: Ha azt akrj, hgy knyssk kpgttni tssk. A másikon: Ha nem akrj, hgy knyssk csngtn tssk.
Na, ez a megoldás. Kell egy write1 függvény, ha azt akarjuk, hogy az adatok kiíródjanak, és kell egy write2 függvény, ha azt akarjuk, hogy az adatok ne íródjanak ki:)
- A hozzászóláshoz be kell jelentkezni
Ebben az esetben hasznalhatod a sync mount opciot, jo lassu lesz tole minden.
- A hozzászóláshoz be kell jelentkezni
Nem jól fogalmaztam, ha az jön le belőle, hogy aggódok a sync hiánya miatt.
Még a múlt évezredben az akkori macskám egyszer végigment a Netware szerver (4.1) billentyűzetén. A szerver összeomlott és a rajta levő fájlrendszer elromlott. Megmaradtak a fájlok, de a directory struktúra megszűnt, az összes fájl valahogy a gyökérbe került. Újra kellett az egészet installálni. Ilyen izéken tárolták akkoriban a "fontos" adatokat. Ehhez képest ... éntőlem nyugodtan allokálhatnak késleltetve.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Khm... ugye, ha úgy döntök, hogy az előbb lezárt dokumentumomat biztonságban szeretném tudni, ezért beírom konzolba, hogy sync, akkor egy perc múlva nyugodtan kiengedhetem a levegőt? :) :-/
...
- A hozzászóláshoz be kell jelentkezni
Csempésztek?!?!
Mindig is ott volt, mióta fejlett (!FAT, !NTFS) filerendszerek léteznek.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Érdekelne, hogy az NTFS miért nem "fejlett".
"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"
- A hozzászóláshoz be kell jelentkezni
Mert az ellensege, es nem lehet elolvasni a forraskodjat, ezert nem biztos, hogy tudsz ra igy 0 byte-os file-t generalni? :)
- A hozzászóláshoz be kell jelentkezni
Lehet 0 bytost file-t NTFS-n is létrehozni.
Egy file rendszer összeomlasztásához nem kell tudni annak a forrásódját olvasni.
Emlékeim szerint az "ellenségnél" hogy legyen e sync vagy nem ,az dönti el ,hogy a hordozót gyors írásra
vagy gyors eltávolításra csatoltad fel.
Bár egy kernel színű fagyástól ez sem óv meg.
- A hozzászóláshoz be kell jelentkezni
Istenkem, az ironait a bitmezokon hagytad? :) Radasaul kivetelesen jol sikerult fs, akarki irta is. Persze, ez csak szerintem :)
- A hozzászóláshoz be kell jelentkezni
Nem fogom a CV-met mindenkinek elküldözgetni, szóval fogadd el azt, hogy hosszú, közeli ismeretség után lett ellenségem, s nem túlfejlett előítélet miatt már előre.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Ezt elfogadom, en sem rajongok erte, de szimplan, es objektiven nezve sok baj nincs vele az _fs_-sel. Es lattam mar nehanyat en is, persze szakertoje nem vagyok.
- A hozzászóláshoz be kell jelentkezni
Valahol azt olvastam, hogy az NTFS egy jól megtervezett fs. Valami másik bagázzsal együtt kezdték el csinálni, már nem emlékszem, OS/2 vagy Mac volt talán, csak aztán különváltak az utak...
- A hozzászóláshoz be kell jelentkezni
Asszem tán HPFS néven indult.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Ez lehetett, mert néhány partícionáló program típushoz azt írja, hogy NTFS/HPFS, tehát nem egyértelműsíti, hogy melyik.
- A hozzászóláshoz be kell jelentkezni
Ez azert az alap muveltseghez tartozik igy a szakman belul.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Végre valaki rájött a google használatára :)
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Az is a jelenlegi IT alap muveltseg korebe tartozik a talalgatas helyett. :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Nekem eddig egy fajlrendszerem szallt el "magatol", es ez pont NTFS volt.
Az igazan vicces az volt benne, hogy a konyvtarakat csak az "s" betuig lehetett olvasni, utana nem. Igy le tudtam menteni minden adatomat amelyik abcben elorebb volt az "s" betunel. Termeszetesen a windows nem indult el, mivel nem latta a "system(32)" konyvtarat;)
De ettol meg lehet jo, meg szuper, ez csak egy pelda. Igaz azota se tartok fontos adatot NTFS-en, legyen akarmilyen biztonsagos.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Szerintem:
1. Teljesen igaza van Ted Ts'o-nak. Ha nem a specifikációnak megfelelően használunk egy API-t, ahogy a fájlrendszert úgy használták, hogy definiáltan definiálatlan állapotokra bízták az adat integritását, akkor ők a ludasak és neki ezzel semmi dolga nincs.
2. A felhasználónak aki rinyál hogy ez regresszió igaza van. A regressziót a fájlrendszer változása hozta, tehát jogos hogy a fájlrendszert hibáztatja. Jogos, de nincs igaza :-).
3. Az alkalmazásfejlesztőknek nincs igaza. Elrontották ahogy használják a fájlrendszert. Most meg pampognak hogy nem működik aminek nem is kellene működni.
A megoldás viszont nincs tekintettel az igazságra. Első lépésként alapértelmezetten tiltani kell az aszinkron írást, de közben rávenni a fejlesztőket hogy rázzák gatyába a fájlkezelésüket.
Általános esetben megoldani hogy minden konzisztens maradjon baromi nehéz feladat. Végleges megoldást csak a fájlrendszerbe épített tranzakciókezelés ad.
Az fsync-es megoldás már csak teljesítmény szempontból sem jó, mert amit nyerünk a késleltetett kiírással azt elveszítjük az fsync-nél amint az összes programba tisztességesen bekerül a hívás.
- A hozzászóláshoz be kell jelentkezni
> Végleges megoldást csak a fájlrendszerbe épített tranzakciókezelés ad.
Ami a diszkekbe épített tranzakciókezelésre épül.
- A hozzászóláshoz be kell jelentkezni
már amelyikben van :)
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
"Az fsync-es megoldás már csak teljesítmény szempontból sem jó, mert amit nyerünk a késleltetett kiírással azt elveszítjük az fsync-nél amint az összes programba tisztességesen bekerül a hívás."
Nem feltétlen, mert pl. gcc minek hívna fsync()-et egy új object file kiírása után?
- A hozzászóláshoz be kell jelentkezni
"Végleges megoldást csak a fájlrendszerbe épített tranzakciókezelés ad."
De a legjobb az lenne, ha ez az API-ban is megjelenne.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
És ezek megjelenésével egyidőben minden mostani posix filerendszer eltűnne a föld színéről, hogy visszafelé kompatibilitással ne kelljen törődni.
- A hozzászóláshoz be kell jelentkezni
Mamrint linux-nal? Szamit? Nem ext4 lesz, hanem next4, aztan jonapot. Eddig meg csak a postfix eseten hallottam, hogy vmelyik filerendszerrel ismetelhetoen gondja lett volna egy user space-ben futo programnak (ettol persze meg lehet ilyen), igy nincs nagy szukseg kompatibilitasra. Persze, lesz akinek nem fog tetszeni /hatalmas tarterulettel, es hasonlok/, de az marad a "regi" fs-nel.
- A hozzászóláshoz be kell jelentkezni
Nem csak Linuxnál. Számít.
- A hozzászóláshoz be kell jelentkezni
No, de miert? Amikor kjott a reiser, senki se probalta ki, mert nem volt kompatibilis az ext2-vel? Vagy az xfs? Vagy a jfs? Lenne, egy hasonlo szal, mint ez, majd elmulna. Lenne, aki utalna, es aki nem, aztan majd kiderul, hogy jo-e.
- A hozzászóláshoz be kell jelentkezni
Miről beszélsz, milyen inkompatibilitás? Egy alkalmazásnak tökmindegy, hogy extN, xfs, reiserfs vagy jfs van alatta, ugyanazokkal a függvényhívásokkal írja-olvassa őket.
Egy valamirevaló alkalmazásnak nem csak egy adott filerendszer + mount opció kombináción kellene megbízhatóan működnie. Tehát hiába jön el egy tranzakciókra képes filerendszer API, amíg a mostani "hagyományos" filerendszerek ki nem halnak, addig támogatni kell őket.
Nem beszélve arról, hogy hogyan használnának a mélyen tisztelt "application developerek" egy ilyen tranzakcionális API-t, amikor egy nyamvadt fsync() ekkora értetlenséget és ellenállást vált ki belőlük.
- A hozzászóláshoz be kell jelentkezni
A "visszafele" kompatibilitasrol. Nem kell kompatibilisnek lennie az ext4-nek, az ext3-mal, csak ha kijelentik, hogy az. Ha mashogy hivjak, es nem asszicial tole az ember az ext sorozatra, akkor nem is elvaras. A tobbi fs-sel arra probaltam celozni, hogy _nem_ kompaitibilisek egymassal, nem volt cel, es elvaras sem.
- A hozzászóláshoz be kell jelentkezni
Lemezformátum szinten nem kompatibilisek (kivéve extN), de API szinten igen. És az alkalmazás szempontjából az utóbbi számít.
- A hozzászóláshoz be kell jelentkezni
ooo, akkor fentiek torolhetoek, elbeszeltunk egymas mellett :)
- A hozzászóláshoz be kell jelentkezni
oké (;
- A hozzászóláshoz be kell jelentkezni
fsync() :)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Gizike, gozeke, fsync? :)
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
most mit kell ezen flémelni
akinek kell a performansz, az vesz egy szünetmentest és használja az ext4-et és örül.
aki meg nem vesz szünetmentest, az meg marad az ext3-nál, ennyi.
- A hozzászóláshoz be kell jelentkezni
Vagy megad egy mount opciot es hasznla ext4 -et, mert meg ugy is gyorsabb.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Sajnos itt a szünetmentes sem segít minden esetben.
Nekem van szünetmentesem, de néha előfordul, hogy úgy lefagy a gép, hogy nem tudom sehogy újraindítani, ilyenkor jön a hard reset.
Illetve volt már olyan áramszünet is, amit nem tudott lekövetni a szünetmentes, 4-5 másodperc hosszan nagyon gyorsan, felváltva ment el, jött meg az áram.
- A hozzászóláshoz be kell jelentkezni
Az én tenyeres talpas paraszt eszemmel csak azt nem értem, hogy az előző postban az volt, hogy nem tudja mennyivel lassabb ha át van kapcsolva másik üzemmódra. Hogy a rákba nem tudja? 20-30%-ról vitatkozunk itt vagy 500%-ról?
Mert szerintem nagyon nem mindegy. Most hogy talán lassan elindul végre az SSD is normálisra, a leglassabb alkatrész (vinyó) is hasonló sebesség változáson megy át mint a gép többi része, akkor itt akár 200% plusz sebesség is jöhet egy év alatt simán. Innen meg pont hogy lesz*rom hogy mennyivel lassabb ha tuti biztonságos.
- A hozzászóláshoz be kell jelentkezni
Mezei usernel 20% alatt-rol szol a vita IMHO.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni