Hirdetés
- Fujifilm X
- Intel Core i3 / i5 / i7 / i9 10xxx "Comet Lake" és i3 / i5 / i7 / i9 11xxx "Rocket Lake" (LGA1200)
- AMD Ryzen 7 / 5 / 3 1***(X) "Summit Ridge" (AM4)
- Steam Deck
- Milyen TV-t vegyek?
- Projektor topic
- Kormányok / autós szimulátorok topikja
- Szünetmentes tápegységek (UPS)
- Házimozi projektorok, kiegészítőik és kialakítások haladóknak
- Soundbar, soundplate, hangprojektor
-
PROHARDVER!
Ide várunk:
- minden saját tapasztalatot/tesztet, észrevételt a már megvett, és használatban lévő SSD-vel kapcsolatban, illetve mindenféle, megbízható forrásból való cikket/tesztet/érdekességet.
Új hozzászólás Aktív témák
-
#16065
Sk8erPeter
nagyúr
patow
#16063
Sk8erPeter
nagyúr
Ez attól függ, hogy ez átlagban kb. milyen mennyiségű írási műveletet jelentene, de azért alapvetően nem erre találták ki - egyelőre - az SSD-ket; ettől függetlenül ha nem írod "szénné", akkor így is üzemelhet akár évekig is. De mondom, teljes mértékben az írási mennyiségtől függ.
Sk8erPeter
-
#16052
Sk8erPeter
nagyúr
RazoR
#16048
Sk8erPeter
nagyúr
Ezt a hozzászólást érdemes elolvasnod:
http://prohardver.hu/tema/flash_ssd_osszefoglalo_az_1_hsz-ben/hsz_719-719.html
Igaz, itt konkrétan Samsung SSD-kről ír Fire/SOUL/CD, de a Te Kingstonodnál sem kell feltétlenül megijedni a 99-es értéktől, az is előfordulhat, hogy maga az érték kijelzése sem feltétlenül megbízható, az is lehet, hogy ez az érték most itt megáll, és így is marad hónapokig, és aztán kezd el megint csökkenni, az is lehet, hogy még lejjebb megy 1-et, és csak utána áll meg picit - persze ebben a felhasználás módja is fontos tényező lehet, de ez inkább csak írással történő "gyilkolászásnál" jelentős -; ami számíthat, az az, ha esetleg feltűnően gyorsan és jelentős mértékben kezdene csökkenni az érték (ekkor kellene csak aggódnod), de szerintem - remélem - nem kell ilyesmitől tartanod. Ezek a minimális csökkenések amúgy eleinte tényleg ijesztően hathatnak, de nem kell tőlük feltétlenül megijedni.Sk8erPeter
-
#16028
Sk8erPeter
nagyúr
Bodor
#16027
Sk8erPeter
nagyúr
"Ha van esetleg elképzelésed, hogy hogyan lehetne az összefoglalót tömörebbre, átláthatóbbra, de mégis elég informatívra átalakítani, akkor tippeket szívesen látok, és ha lesz időm átnézem, és átszerkesztem."
OK. Arra gondoltam, hogy annak érdekében, hogy a kezdőnek ne menjen el a kedve a bőséges információtenger láttán attól, hogy továbbolvasson (sok link van, a legtöbb cikk nagyon hosszú egy kezdő számára, még ha igényesek is, és jól jöhetnek később), és inkább lustaságból ne tegye fel a topicban a kérdését, vagy halasztgassa későbbre a probléma-megoldást (egyik sem jó), lehetne inkább kapásból az elején, az általános SSD-kről szóló bemutató előtt egy pár pontból álló, rövid, gyors áttekintő összefoglaló (kapásból itt szerepelhetne az összefoglalóban, nem pedig indirekció(ko)n keresztül, különböző linkekre kattintva elérhető cikkekben), egy kis kivonat, hogy alapvetően ezekre, meg azokra kellene figyelni, aztán ezután jöhetne az adott részeknél, hogy ha bővebben is szeretnél róla olvasni, akkor itt vannak a további cikkek, ezek közül például a tiéd is lehetne valahol elöl, mert az tényleg zanzásítva összefoglalja a lényeget.
Sztem nagyon sok kezdőt kevésbé izgat, hogy mely driverek mitől jók vagy rosszak, nem is szeretnek túl sokat olvasni (ez még érthető is, mert mindenki szereti az elején megkapni a lényeget minél előbb, aztán mélyebbre is áshat a témában, ha érdekli), ezért is hangzik el nagyon sok ismétlődő kérdés.Egyszerű megoldásként lehetne javasolni, hogy Windows esetén hagyják fent az alapértelmezett Microsoftos drivert, ha sebesség-problémákat tapasztalnak, vagy csak kíváncsiak, próbálkozhatnak mással is; meg hogy tényleg csak azokat a drivereket rakják fel, amikre valóban szükségük van, lehetőleg tallózós módszerrel. Le lehetne írni, hogy az AHCI-t állítsák be a BIOS-ban (anélkül, hogy leírnánk az elején, mi az, max. becsillagoznánk a magyarázatot későbbre), azt is kihangsúlyozni, hogy nem kell félni az SSD-re írástól, nem kell áthelyezgetni nagyon semmit, és nyugodtan particionálják az SSD-t, nem okoz semmilyen problémát (ez a kérdés is sokszor felmerül); a lapozófájl méretét igény szerint állítsák kisebbre, de hibernációt pedig csak akkor kapcsolják ki, ha tényleg nem használják, 8-astól felfelé Windows-nál meg lehetőleg már ne lőjék ki egyáltalán (a gyorsabb boot miatt).
Kb. ilyesmikre gondolok, ezt pár pontba szedve az elején leírva (meg esetleg még egy-két alapvető dolgot, ami most nem ugrott be), aztán lehetne az összes többi, ami most van, mert azok jól és igényesen vannak rendszerezve, de sztem jól jönne egy ilyen kivonat is az elejére a hatékonyság jegyében.Sk8erPeter
-
#16001
Sk8erPeter
nagyúr
Doky586
#15999
Sk8erPeter
nagyúr
válasz
Doky586
#15999
üzenetére
Azt a kurva, te nagyobb idióta vagy, mint gondoltam.
Vágod, hogy a Prohardver rangrendszere szerint lehet valaki félisten? 
De nagyon remélem, hogy mindezt tudod, csak játszod a kretént (bár elég sokszor volt példa rá). 
Tessék. Az összes PH! nagyúrnak esetleg nem nem akarsz beszólni a rangjuk megnevezése miatt? Aztán jöhetnek a moderátorok, ők se maradjanak ki.
A jelenség normális, mivel ez az adottság az AHCI-ból következik. Attól még, mert neked nem tetszik, és attól függetlenül, hogy van rá kerülő megoldás (akár hardveresen, akár szoftveresen tiltod le), ez így van. Nem kell mindent dramatizálni, mindenen feszkózni, csak hogy kiemelkedj a tömegből, nyugi, nem ez a megfelelő hely az ilyesmik levezetésére.Sk8erPeter
-
#15998
Sk8erPeter
nagyúr
Doky586
#15997
Sk8erPeter
nagyúr
válasz
Doky586
#15997
üzenetére
Te miről beszélsz, emba'?
Hogy ezekre a következtetésekre milyen belső komplexusok vezettek, azt nem tudhatom, de a hozzászólásom annyiról szólt, hogy javítottam a hibás megjegyzésedet. Még egyszer: de, normális a kérdező által említett jelenség. Tán olvasd el még egyszer a hsz.-t, pontosan ennyit tartalmazott, nem többet (amiket még beleláttál 
).Sk8erPeter
-
#15996
Sk8erPeter
nagyúr
Doky586
#15995
Sk8erPeter
nagyúr
válasz
Doky586
#15995
üzenetére
De igen, teljesen normális. Másnál is van ez a jelenség, mint a hozzászólásomban látható linkekben szerepel. Vágod, AHCI "allows the use of advanced features of SATA such as hotplug and native command queuing (NCQ)"...
Sk8erPeter
-
#15985
Sk8erPeter
nagyúr
sid87
#15982
Sk8erPeter
nagyúr
Igen, ez így "normális", de Windows 7 esetén meg lehet oldani a problémát némi registry-turkálással, kizárólag saját felelősségre, és nagyon odafigyelve csináld, semmit ne törölj, stb.:
http://superuser.com/questions/12955/how-can-i-remove-the-option-to-eject-sata-drives-from-the-windows-7-tray-icon/121015#121015
vagy adminként parancssorból:
http://www.tomshardware.co.uk/forum/267124-32-hard-drive-showing#5985811Windows 8-nál állítólag ez nem működik, erről nem tudok nyilatkozni.
Amúgy az USB Safely Remove segítségével is elrejthetőek az ilyen eszközök.
Sk8erPeter
-
#15977
Sk8erPeter
nagyúr
Emperor_
#15970
Sk8erPeter
nagyúr
válasz
Emperor_
#15970
üzenetére
"A képek, doksik áthelyezése miért jó? A felesleges helyfoglalás jut csak eszembe. De valahogy nekem nem életszerű, hogy több ezer képet és doksit tároljak egyszerre e mappákban..."
Nem értem, miért ne lenne életszerű?
Önmagában szted az nem életszerű, hogy egy könyvtárban többezer fájl/alkönyvtár lenne? Pontosan így van pl. nálam is: többezer doksi van alkönyvtárak formájában a dokumentumok könyvtárában, többezer kép a képekében. Egyrészt mégis mi lenne ezzel a probléma, másrészt miért lenne jó, ha ezek a dedikált könyvtárak az SSD-n lennének? (#15973) fer:
Sk8erPeter
-
#15976
Sk8erPeter
nagyúr
honda130
#15971
Sk8erPeter
nagyúr
válasz
honda130
#15971
üzenetére
Egyetértek, hogy egyszerűen túl sok kapcsolódó cikk van az összefoglalóban, és a kezdő nem tudja eldönteni, hogy most akkor mi is kell neki. Kéne egy párlépéses összefoglaló doksi, és kész, a többi már csak érdekességnek lenne belinkelve.
A lényeg: állítsd be az AHCI-t a BIOS-ban, azt pedig saját magad döntsd el, szeretnéd-e particionálni az SSD-t vagy sem (se rosszat, se jót nem tesz, csak akkor érdekes, ha vannak például hordozható programjaid, amiket nem szeretnél megint felrakni egy újratelepítéskor), aztán telepítsd az oprendszeredet, majd azokat a drivereket, amelyeket feltétlenül hiányol a Windows, és kész. Lehetőleg ne használj komplett drivertelepítő csomagokat, amik ki tudja, miket pakolnak még fel, amikre nincs is szükséged. Az SSD-hez tartozó alapértelmezett driver teljesen jó.A többi lépés opcionális, mert egy korszerű operációs rendszernél túl sok mindent nem kell beállítani. A lapozófájl méretét szokás még a defaultnál kicsit lejjebb venni. Illetve az egyéni döntés, hogy szükséged van-e a hibernálás lehetőségére (amikor áramtalanítod a gépet, de úgy, hogy vissza tudd állítani a korábbi állapotot, ahol épp tartottál), ha nincs, akkor pusztán helyspórolás miatt érdemes lehet kikapcsolni.
Egyáltalán nem kell foglalkoznod ilyesmivel, mint a böngésző gyorsítótárának áthelyezése másik háttértárra, mert hasonló baromságok, mert semmi értelme, csak arra jó, hogy apró lépésenként lassítsd az épp gyors rendszeredet. Ha van egyéb kérdés, nyugodtan tedd fel.
Sk8erPeter
-
#15966
Sk8erPeter
nagyúr
akos3
#15962
Sk8erPeter
nagyúr
Na, királyság, örülök, hogy így összejött.
Amúgy ja, a felhasználói könyvtáradban lévők közül ezeket teljesen jogos, hogy áthelyezted, de a többivel, amik miatt aggódtál, nem érdemes foglalkozni, így azon se aggódj, hogy pölö a Chrome az SSD-re írkál, hadd tegye. Az a ritkább eset átlagfelhasználói igényeknél, hogy az írástól megy tönkre az SSD belátható időn belül, előbb szokott a vezérlő elhalálozni.(#15964) jakos73:
Valami eredetibb oltással állj már elő, ez már nekem kínos.
Amúgy a lényeg az volt, hogy ha nem vagy biztos a dolgodban, pl. mert nem értesz a téma adott szegmenséhez (ez nem jelenti azt, hogy a téma többi részéhez adott esetben ne tudnál hozzászólni, de nem szégyen belátni, hogy van olyan, amit nem vág az ember), akkor utánanézés előtt ne jelents ki általánosságokban dolgokat, mert egy szakmai topicban elvárható az ilyen jellegű igényesség (pl. ha valaki betéved a topicba, még a végén elhiszi a téves állítást).Sk8erPeter
-
#15959
Sk8erPeter
nagyúr
Predator2
#15958
Sk8erPeter
nagyúr
válasz
Predator2
#15958
üzenetére
Bele lehet tenni. Ott van az általad linkelt AIDA64-doksiban:
"Háttértár:
IDE vezérlő Szabványos AHCI 1.0 Serial ATA-vezérlő
Lemezes meghajtó TOSHIBA MK3276GSX ATA Device (320 GB, 5400 RPM, SATA-II)
Optikai meghajtó hp DVDRAM GT50N ATA Device (DVD+R9:6x, DVD-R9:6x, DVD+RW:8x/8x, DVD-RW:8x/6x, DVD-RAM:5x, DVD-ROM:8x, CD:24x/24x/24x DVD+RW/DVD-RW/DVD-RAM)[...]
[ TOSHIBA MK3276GSX ATA Device ]
[...]
Csatoló: SATA-II
[...][ hp DVDRAM GT50N ATA Device ]
[...]Optikai meghajtó tulajdonságai:
Gyártó Hitachi-LG
Eszköz típusa DVD+RW/DVD-RW/DVD-RAM
Csatoló: SATA"Valószínűleg a HDD helyére kell majd tenni, hogy legalább SATA2-n üzemeljen, nem tudom, ez mennyire probléma az illetőnek.
Sk8erPeter
-
#15957
Sk8erPeter
nagyúr
akos3
#15954
Sk8erPeter
nagyúr
Ja, ez para, de ne aggódj, vissza lehet csinálni. Az lehet a gond, hogy most kb. megpróbálja az egész E: betűjellel ellátott partíciód ÖSSZES (!) tartalmát áthelyezni (számára visszapakolni, mert vissza akarja állítani az alapértelmezést) a C:\Users\Akos\Documents könyvtárba, de nem tudja megtenni, mivel a System Volume Information könyvtárat így "menetközben" nem mozgathatod akárhova, nincs hozzá jogosultságod (épp erre hivatkozik a hibaüzenet).
Ha az általad linkelt képen is látható Áthelyezés gombra kattintasz, majd megadod a célhelyet, akkor emlékeim szerint megkérdezi, hogy minden, az eddigi könyvtárban lévő fájlt is át szeretnél-e helyezni a másik könyvtárba - erre alapvetően igennel kellene válaszolni, DE MOST válaszold azt, hogy NEM, nem szeretnéd; a lényeg, hogy egyszerűen csak ennek a könyvtárnak az elérési útja (legalábbis ahova mutat) legyen megváltoztatva.
Rákerestem, itt is írja valaki, hogy ez így működőképes lenne, amit javasoltam.(#15953) Predator2:
Szerintem megéri gyengébb konfiggal is venni SSD-t, legalább a komoly szűk keresztmetszetet jelentő HDD lassúsága miatt nem kell szenvedni. SATA2-es tempóval fog üzemelni (tehát a benchmark méréseitől nem kell megijedni), de így is megérheti, ha van pénze rá az illetőnek.(#15956) fer:
Szerintem még mindig nem érted az alapproblémát (amit meg kell oldani, függetlenül attól, hogy hogyan jutott el ide). Egyébként de, megéri áthelyezni a felhasználói könyvtárban lévő dedikált könyvtárakat (például a dokumentumok, képek, videók dedikált mappáját is simán megéri - igazából miért is ne? Minek is tárolja ezeket az SSD-n?).(#15946) fer:
"Vagy telepíts, vagy videózz! Nem is értem, hogy miért kell videó nézés közben telepíteni"
Azt a qrva, úgy látom, egy-két topiclakónak az agyára is húzódott a bejgli. Egy-két ilyen aranyköpést még, légyszi, nagyon szórakoztató! ![;]](//cdn.rios.hu/dl/s/v1.gif)
[ Szerkesztve ]
Sk8erPeter
-
#15952
Sk8erPeter
nagyúr
Ice&Lime
#15934
Sk8erPeter
nagyúr
válasz
Ice&Lime
#15934
üzenetére
Csak kibújt a szög a zsákból (sejthető volt, hogy ide lyukad ki a téma): tehát ezek szerint fogalmad nincs a RAID-témáról, de általánosságban jelentesz ki dolgokat róla, és minősíted hülyeségnek? Ez azért egy szakmai topicban para. Honnan tudod, hogy ha valaki RAID-tömb mellett tette le a voksát, akkor azt milyen okból tette, és csupán átlagfelhasználói igényei vannak-e, mint neked?
(#15925):
"Átlagemberként (sokan vannak így ezzel még egyébként) ilyenre azért nem is lenne szükségem, mert: felesleges, költséges, több meghajtó-több probléma. Akinek pedig erre szüksége van és megakarja csinálni, az nyilván akkor is megcsinálja, hiába olvasta azt, hogy mert nem éri meg és kockázatosabb megoldás."
Mint korábban elmagyaráztam, ez a "kockázatosabb megoldás", meg az is, hogy "felesleges", ebben a formában színtiszta baromság még mindig. Egyszerűen nem lehet ilyet általánosságban jelenteni, széjjel lehet cincálni ezt az állításodat, már többen megtettük. Léteznek magasabb RAID-szintek is a 0-snál. Még akkor is, ha a srácnál jól látható módon RAID0-ról volt szó (ami valóban nem tolerálja egy meghajtó kiesését sem), akkor sem jelenthetsz ki általánosságban a RAID-ről valamit, ha nem értesz hozzá, és egyetlen szintjénél nem ismersz többet.(#15937) jakos73: ezt a ráadást még csak most látom.
"Ez a terület nem ssd specifikus, ezért nem is érdekel.
Akit ez annyira érdekel, ezt miért nem lehet a 10 éve működő raid topikban intézni és miért itt kell lovagolni rajta?"
Ez nagyon kemény. Tehát ha téged nem érdekel, és nem is értesz hozzá, akkor elég annyival elintézni, hogy "nem éri meg, kockázatos megoldás", és meg is van oldva, legalább akkor nem beszélnek róla?
Ha SSD-ket raknak valamilyen RAID-tömbbe, akkor szerinted az nem tartozik a topicba, mert zavar, hogy nem tudsz hozzászólni? Elég furákat írogatsz most.(#15929) Doky586:
"A kérdező Raid0-ról beszélt....... ti próbáljátok másra terelni a szót"
Ahogy nálad már megszokhattuk, megint csak megjelentél, és anélkül, hogy körülnéztél volna, és az előzményekkel tisztában lennél, idelöktél valami okoskodót. Azért segítek. jakos73 jelentett ki a RAID-del kapcsolatban olyat, ami totál baromság. Itt már én is leírtam, hogy RAID 0-ról van szó, de az egy f@szság általánosságban, hogy a RAID "nem éri meg és kockázatosabb megoldás". Remélem, utóbbival még te is egyetértesz.[ Szerkesztve ]
Sk8erPeter
-
#15951
Sk8erPeter
nagyúr
akos3
#15917
Sk8erPeter
nagyúr
Nem ezt írtam, ha elolvasod még egyszer.
Amit Te nézel, az a "Könyvtárak" csomóponton belül van, az tök más, oda saját szempontok szerint rendezett és elnevezett könyvtárszerűségeket hozhatsz létre, ami igazából csoportosításra, meg az elérési utak gyorsabb megtalálására jó. De fizikailag nem helyezel át vele semmit.
A felhasználói könyvtáradba lépj bele, ami esetedben a c:\Users\Akos lesz. Ott pedig a különböző dedikált könyvtárakra (pl. Desktop, (My) Documents, (My) Downloads, (My) Music, (My) Videos, stb.) kell rákattintani jobb egérgombbal, majd a tulajdonságaira rákattintani, és beállítani a Location fülön az elérési utat, a Move gombbal mozgathatod máshová (nyilván helyettesítsd be magyar nevekkel magyar OS-nél).
Rákerestem neked, van magyarul is, screenshotokkal:
http://windows.microsoft.com/hu-hu/windows/redirect-folder-new-location#1TC=windows-7Az asztal könyvtárát pontosan ugyanígy átmozgathatod másik háttértárra, csak nem érdemes: nem mindegy, az asztal mennyi idő alatt jelenik meg, szóval maradjon csak SSD-n. (Persze SSD-n belül mehet másik partícióra ízlés szerint, nálam is ez a helyzet, mert vannak az asztalon olyan shortcutok, amik aktuális rendszertől függetlenül kellenek.)
Az Asztalra pedig ne rakj fizikailag fájlokat/könyvtárakat, hanem inkább max. azokra mutató linket pakolj ki.Amúgy meg azért az áthelyezősdit nem érdemes túlkattogni, hogy másik háttértárra kerüljenek a programok/egyebek, mert egy idő után eljutsz oda, hogy elkezded szépen lelassítani a rendszeredet.
A dokumentumaidat és képeidet, meg letöltéseidet viszont érthető, hogy át akarod helyezni HDD-re, hogy ott terpeszkedjenek, és szívesen használod ehhez a Windows dedikált könyvtárait erre a célra.Directory junction nagyon leegyszerűsítve: lényegében megcsinálhatod vele, hogy amikor a C:\Kiskutya könyvtár tartalmát böngészed vagy írod, akkor valójában a D:\Nagykutya könyvtár tartalmát böngészd vagy írd.
(#15920), (#15921) Emperor_:
"A user könyvtárak átpakolászása is felesleges."
Egyáltalán nem felesleges például a dokumentumok és képek, esetleg a letöltések tárolására szánt könyvtár áthelyezése másik háttértárra, sőt, érdemes.Egyébként sajnos még a Visual Studio is van olyan ostoba ilyen szempontból, hogy MUSZÁJ a rendszerpartíción tárolni az adatainak egy nagy részét, hiába helyezed át másik partícióra a többi részt a telepítés során, mindenképpen lesz valamennyi a rendszerpartíción. Szeretem azt a fejlesztőkörnyezetet, egy nagyon komplex, és szinte kezed alá dolgozó eszköz, de ilyen szempontból szánalmasan buta.
[ Szerkesztve ]
Sk8erPeter
-
#15916
Sk8erPeter
nagyúr
akos3
#15913
Sk8erPeter
nagyúr
"Egyedül a letöltéseket tudtam átirányítani oda, a dokumentumok, képek, zenék stb..az mind sajnos egyelőre az SSD-t foglalják"
Pedig ezeket a dedikált mappákat nyugodtan át tudod helyezni Windows esetén mindenféle külön trükk nélkül, egyszerűen jobb klikkelsz ezekre a felhasználói könyvtárban lévő mappákra, majd a tulajdonságoknál a Location fülön, a "Move..." gombbal simán áthelyezheted őket egy másik elérési útra...A többire esetleg directory junction vagy hardlink lehet a megoldás.
mklink/junctionSk8erPeter
-
#15915
Sk8erPeter
nagyúr
Ice&Lime
#15908
Sk8erPeter
nagyúr
válasz
Ice&Lime
#15908
üzenetére
"Csak röviden, a minimális 2 db ssd, ha már 2db ssd az már 2db vezérlő, 2x-es rizikó, ha 4 ssd, akkor 4x-es rizikó, ezért akkor már inkább egy darab nagy méretű ssd és ebben az esetben legalább már csak 1 db vezérlő mehet tönkre. Ezért."
Hát hogyne. Sajnos sejtettem, hogy ez lesz az érvelés alapja, és amúgy ezért is kérdeztem, hogy milyen RAID-tömbről is beszélünk, de erre nem válaszoltál, ezért pont olyan szabadon értelmezhető a kijelentésed, mint amilyennek tűnik, épp ezért írtam, hogy abban a formában nagyon nagy butaság. Értelmezzük, amit írtál: tehát akkor ha például tükrözve vannak az adataid két azonos eszközre (pl. egy egyszerű RAID 1 esetén), akkor szerinted kétszeres az adatvesztés kockázata, míg ha egyetlen egy darab eszközön vannak meg, akkor az úgy sokkal biztonságosabb? Az érvelésedből sajnos ez következik. Amit írsz, az alapján a RAID valami ördögtől való dolog lenne, hiszen minél több eszköz, annál nagyobb a meghibásodás valószínűsége, de akkor már az adatvesztés kockázata is. Sőt, a meghibásodás ugyebár nem SSD-specifikus dolog, a HDD-knél pontosan ugyanúgy előfordulhat. Tehát akkor ezek szerint soha nem érné meg RAID-tömböket használni... (A vezérlőelektronika ugye rossz esetben a HDD-knél is bármelyik pillanatban felmondhatja a szolgálatot.)A srácnál úgy tűnik, RAID 0 van, ahol valóban elegendő egyetlen meghajtó meghibásodása, így ez tényleg kockázatos lehet. De érdemes megnézned magasabb RAID-szinteket is, most csak példa kedvéért van pl. a min. 3 meghajtót igénylő RAID 5, azt már elosztott paritás jellemzi, és 1 db meghajtó meghibásodása még simán tolerálható.
Igazából a korrekció célja az volt, hogy általánosító kijelentéseket úgy érdemes tenni, ha lefixáljuk, milyen esetben is igazak az állításaink...Sk8erPeter
-
#15907
Sk8erPeter
nagyúr
Ice&Lime
#15889
Sk8erPeter
nagyúr
válasz
Ice&Lime
#15889
üzenetére
"Raid-del nem foglalkozom (mert nem éri meg és kockázatosabb megoldás)"
Ezt nem tudom szó nélkül hagyni, indokold már meg légyszi, hogy mire érted azt, hogy "kockázatosabb megoldás"? Ja, és főleg mihez képest, és melyik RAID-tömbről beszélsz? Csak mert ebben a formában a kijelentésed - mindenféle megbántás szándéka nélkül - nagyon nagy butaság.Sk8erPeter
-
#15699
Sk8erPeter
nagyúr
Ice&Lime
#15698
-
#15697
Sk8erPeter
nagyúr
Ice&Lime
#15691
Sk8erPeter
nagyúr
válasz
Ice&Lime
#15691
üzenetére
Pedig ott van a magyarázat Fire/SOUL/CD egyik cikkjében:
http://logout.hu/bejegyzes/fire_soul_cd/windows_7_telepitesi_utmutato_ahci_edition.html"Tömörítést használó SSD-knél ne tömöríthetetlen (incompressible) adatokkal mérj. (Pl CrystalDiskMark esetén All 0x00 (0 Fill) módszerrel mérj.)
Erre azért van most szükség, mert a tömörítést használó SSD-k (pl. Sandforce vezérlősek) tömöríthetetlen adatokon lassabb mérési eredményeket adnak, viszont ez esetben az elméleti maximum sebességre vagyunk kíváncsiak, hogy azt a gyártó adataival összevetve meg lehessen állapítani, hogy az SSD tényleg a tőle elvárható sebességet hozza/közelíti-e meg. (Tömöríthetetlen adatokkal végzett teszt esetén egy Sandforce vezérlős SSD-ről nem feltétlenül tudnád megállapítani, hogy azért lassú, mert tömöríthetetlen adatokkal annyit tud, avagy azért, mert mégsem a megfelelő SATA port-ra dugtad avagy rosszul állítottad be a BIOS-t vagy egyéb probléma áll a háttérben)"Szóval ha valaki ki akarja zárni az esetleges egyéb okokból jelentkező potenciális hibákat első körben, és össze akarja hasonlítani gyárihoz legalább valamennyire közeli értékekkel, akkor igenis van jelentősége a 0 Fill beállításnak. Értelmesebb, ha ezt használják az emberkék, mert akkor legalább nem ijednek meg a kapott eredményektől.
Sk8erPeter
-
#15680
Sk8erPeter
nagyúr
dobostorta
#15679
Sk8erPeter
nagyúr
válasz
dobostorta
#15679
üzenetére
Nyugodtan csinálhatsz előtte és utána is, nem ez az írási mennyiség fogja tönkretenni az SSD-det... (Ahogy még nagyon sok másik sem.
)Sk8erPeter
-
#15524
Sk8erPeter
nagyúr
kpal
#15523
Sk8erPeter
nagyúr
AHCI-módra érdemes állítani (bár "újabb" gépeknél ez a default), drivert nem kell hozzá telepíteni (lehet, de az alapértelmezett Microsoftos driver is teljesen jó (gondolom Windows-ról van szó; 7-esnél ez amúgy 2006-os)), és főleg kerüld a chipsetdriver-csomagokat, amik az alaplapi CD/DVD-hez járnak, teljesen felesleges dolgokat is felrakhatnak. A gépre a hiányzó drivereket egyesével telepítsd, de csak azt, ami tényleg kell (lehetőleg tallózós módszerrel az Eszközkezelőben, ha tudod, hogy kell; bár csábító lehet az ilyen Next-Next-es installálós módszer, de én már inkább kerülöm jóideje, szeretem tudni, ténylegesen mi is kerül a gépre).
Aztán az összefoglalóban van rengeteg cikk, amikben válaszokat kapsz a felmerülő kérdésekre.[ Szerkesztve ]
Sk8erPeter
-
#15517
Sk8erPeter
nagyúr
kpal
#15516
Sk8erPeter
nagyúr
Ha a vezérlőelektronika fel nem adja a harcot, akkor mindenképpen több évig jó lesz, akkor is, ha játékokat raksz az SSD-re, azok tipikusan nem hajtanak végre annyi írási műveletet, hogy az releváns legyen az élettartam szempontjából. Szerencsére már megdőlt az a régi hiedelem, hogy az SSD-ket mindenáron pátyolgatni kellene - nem kell.
(Éppen ezért nem érdemes a lapozófájlt sem áthelyezni/kikapcsolni, nem kell tiltani a hibernációt (bár ha nem használod, akkor feleslegesen foglalja a helyet), stb...)Szerk.: HDD-vel ettől még nem érdemes összemérni az élettartamát, az tartósabb, de az SSD-től sem kell félni jobb esetben, hogy holnapra meghal (ez egyébként bármikor bekövetkezhet bármilyen hardvernél), de persze a fontos adatokról mindig legyen backup (sablonduma, de az ördög sosem alszik).
[ Szerkesztve ]
Sk8erPeter
-
#15515
Sk8erPeter
nagyúr
janos666
#15514
Sk8erPeter
nagyúr
-
#15512
Sk8erPeter
nagyúr
kpal
#15511
Sk8erPeter
nagyúr
Pár játék aztán igazán nem árt neki.
Szerk.: de azzal számolj, hogy sok játéknál ez csak a betöltési folyamatot gyorsítja (magának a játéknak a betöltését, meg pl. a pályáknak a háttértárról történő betöltését), a játék ettől nem lesz "pörgősebb", meg több FPS-t sem kapsz (ott már a többi hardver számít).[ Szerkesztve ]
Sk8erPeter
-
#15452
Sk8erPeter
nagyúr
janos666
#15451
Sk8erPeter
nagyúr
válasz
janos666
#15451
üzenetére
Mi van? "Megfutamodtam" a "feladatom" elől?
Szerinted nekem az "feladatom", amit te kigondolsz? Mivel helytelenül írtad, jogos volt a megjegyzés (a CrystalDiskMark teljesen lényegtelen az egészben, annyiból érdekes legfeljebb, hogy ott helyesen írják a mértékegységet), ha MB/s-ként írod, ami a bevett szokás, akkor egyértelmű, hogy megabájtról van szó, de lehetett volna MBps is, a Mbps megabitre vonatkozik a konvenció szerint, az IOPS-ot pedig a konvenció szerint megint csak így írjuk, ahogy van, azért vannak ezek a szokások, hogy mindenkinek egyértelmű legyen, miről is van szó, de ennyire tényleg nem volt fontos az egész, azt hittem, ennél lazábban veszed az ilyen jellegű pontosító megjegyzéseket, még ha van benne egy kis szúrkálódás is. De ha ilyen véresen komolyan veszed, ekkora válasz helyett inkább rakd ki betűtésztából a nickneved - nehogy már mi vesszünk össze, eddig legalább mi jól elvoltunk a szakmai témázásokkal, maradjunk is ennél. Mivel látom, mekkora sértődés van a pontosításokból, akkor majd legközelebb megtartom magamnak, bár te is írhatnád pontosan az ilyesmit, na. 
Sk8erPeter
-
#15450
Sk8erPeter
nagyúr
janos666
#15449
Sk8erPeter
nagyúr
válasz
janos666
#15449
üzenetére
Atyaég, itt mindenki azonnal besértődik egy kis kekeckedéstől, ne legyen már ennyire alacsonyan az a bizonyos ingerküszöb...
Azt írtad, hogy Mbps, az márpedig megabit per secundum, nem pedig megabájt, de mindegy, hagyjuk, azt reméltem, hogy átjön elsőre is, de helyette inkább megsértődtél, mint mások, "mint mindig". Sk8erPeter
-
#15446
Sk8erPeter
nagyúr
janos666
#15444
-
#15412
Sk8erPeter
nagyúr
fer
#15411
Sk8erPeter
nagyúr
Most tényleg csak az a rész jött át belőle, hogy a particionálást AKÁR lehet használni arra is, hogy több eltérő fájlrendszert is használj azonos eszközön? Az ő kérdése az volt, hogy "Érdemes particionálni az SSD-t?", erre itt megadtam a választ, miszerint ez teljesen egyéni döntés kérdése, attól függ, hogy akar-e félrerakni egy partíciót arra, hogy ott esetleg olyan adatokat tároljon, amiket egy újratelepítés nem érint, és így nem is kell lementegetnie azokat. És akkor még egyszer elmondom: az esetleges töredezettségnek SEMMI köze ahhoz, hogy érdemes-e particionálni vagy sem, teljesen mindegy, hogy milyen eszközről beszélünk. Senki nem is kérdezte, hogy kell-e egyáltalán defragolni az SSD-n. Nyilván nem kell, ez fel sem merült.
Sk8erPeter
-
#15408
Sk8erPeter
nagyúr
fer
#15404
Sk8erPeter
nagyúr
"Mivel az ssd nem töredezik szerintem a particionálásnak semmi értelme"
Mi köze a töredezettségnek a particionálás létjogosultságához?
Semmi. Sosem telepítettél még újra oprendszert particionált háttértáron? A particionálásnak mindössze annyi a lényege, hogy az egyes partíciók különálló egységet képezzenek. Nem azért kell vagy épp nem kell több egységre (több fájlrendszerre, amik lehetnek azonos típusúak vagy különbözőek (pl. lehet azonos háttértáron egy ext2-, egy ext4-, egy FAT32-, egy NTFS-,stb. fájlrendszered is)) osztani a meghajtódat, hogy ne legyen vagy épp legyen töredezett, ez még csak fel sem merül szempontként a döntésben.
(#15407) freestailo:
Na az tényleg érdekes, ha valóban ez volt a probléma megoldása. (és nem történt közben más is, amitől megoldódhatott)(#15403) xuldar:
Ez is igaz, én is elfogadnék egy 2450 GB-os SSD-t.[ Szerkesztve ]
Sk8erPeter
-
#15402
Sk8erPeter
nagyúr
gameresboy
#15401
Sk8erPeter
nagyúr
válasz
gameresboy
#15401
üzenetére
Ez teljes mértékben rád van bízva, ahogy neked kényelmes. Értsd: rosszat nem teszel egyik sem, amíg jól elférsz minden partíción. A particionálás mellett szól, hogy így OS-újratelepítés során nincs szükség az esetleges portable-programok, vagy más okból SSD-n tárolt, átmentendő adatok mentegetésére, majd újból visszarakására, hiszen az külön partíción tárolódik, de a particionálás ellen szól, hogy egy nagy partíción mindenképp optimálisan férsz el, nincs olyan helyzet, hogy mondjuk rosszul sikerült kitalálnod a partícióméreteket, és így valamelyik partíción helyhiányban szenvedsz (pl. a rendszerpartíción kellemetlen tud lenni).
Sk8erPeter
-
#15339
Sk8erPeter
nagyúr
margithid
#15336
Sk8erPeter
nagyúr
-
#15310
Sk8erPeter
nagyúr
Doky586
#15308
Sk8erPeter
nagyúr
válasz
Doky586
#15308
üzenetére
"Nálam is a BB6Q van a restoration soft futtatása után"
840 EVO legfrissebb firmware-je az EXT0CB6Q.
Lásd: [link].Plusz:
http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/support/downloads.html
"Samsung SSD 840 EVO Performance Restoration Software
Samsung is releasing a new firmware and performance restoration software package for the 840 EVO and 840 EVO mSATA.
The firmware update is recommended to users who may have experienced any drop in read performance of the mentioned drives.
Running the software packages provided will first update the firmware(840 EVO : EXT0CB6Q, 840 EVO mSATA : EXT42B6Q), then scan and calibrate all existing data on the drive."[ Módosította: radi8tor ]
Sk8erPeter
-
#15307
Sk8erPeter
nagyúr
freestailo
#15306
Sk8erPeter
nagyúr
válasz
freestailo
#15306
üzenetére
Ha jól értettem, a firmware-frissítést a Performance Restoration szoftverrel ejtetted meg, nem pedig külön frissítetted, ez alapján elvileg újra is íródtak az adatok, amikor ez megtörtént, tehát elméletileg nem a régi adatok olvasásával kapcsolatos a probléma (legalábbis remélem, hogy nem fog kiderülni, hogy ez a firmware sem az igazi
).
Nincs esetleg valami vezetéknélküli egér+billentyű kombód, aminek az adaptere be van dugva a gépbe? Faterom gépén voltam random rohadt zavaró akadozgatások, és mint kiderült, a Microsoft Wireless Desktop 3000 adóvevője miatt játszotta az agyát, és egy plusz USB-kábellel meghosszabbítva, az adóvevő egységet távolabb helyezve a géptől minden rendbejött... Ahogy elnéztem, Microsoftos vezetéknélküli egységek esetén egész gyakran fordul elő ilyesmi.Ha nem ilyen jellegű a probléma, akkor érdekes a dolog, ilyenkor lehet, hogy egy komplett adatmentés utáni secure erase-t érdemes lenne megejteni (még egyszer: az adatmentés fontos, mert ez mindent törölni fog az SSD-ről igen alaposan, de pár másodperc alatt), majd a backupból visszamásolni az SSD-re az adatokat, most hirtelen jobbat nem tudok.
Szerk.: próbát megér, persze lehet, hogy ez sem old meg semmit, akkor tovább kell vizsgálódni, hogy mi lehet a hiba forrása.[ Szerkesztve ]
Sk8erPeter
-
#15288
Sk8erPeter
nagyúr
janos666
#15287
Sk8erPeter
nagyúr
válasz
janos666
#15287
üzenetére
Az általad írt esetek természetesen helytállóak, ezek pont nem azok a helyzetek, amikor az SSD erőssége megnyilvánul, de én pont az általánosító részére reagáltam, hogy ti. nem jelenthető ki, hogy az SSD-ről gyorsabb lesz bármi - de azért az esetek túlnyomó többségében kijelenthető, hogy egy OS és az alkalmazások, meg egyes fájlok betöltési ideje például a HDD-hez képest jelentősen gyorsul, így az általános felhasználási élmény javul, és épp ezért összességében megéri váltani. Annak persze, hogy nincs értelme, hogy "váltsá' esesdére, merakkó gyorsabbak lesznek a játékok", mert az így nem lenne igaz. Szóval csak megközelítés kérdése, hogy mire jelentjük ki, hogy várható gyorsulás az SSD-től, és elég sok ilyen esetet is lehet említeni.
[ Szerkesztve ]
Sk8erPeter
-
#15281
Sk8erPeter
nagyúr
janos666
#15280
Sk8erPeter
nagyúr
válasz
janos666
#15280
üzenetére
"Az egyáltalán nem biztos, hogy SSD-ről gyorsabb lesz bármi"
Mondjuk ez a mondatrész ebben a formában erősen kifogásolható. A memóriához képest nyilván nem lesz gyorsabb, de a legtöbb elterjedt adattárolóhoz képest - amennyiben pl. elérési időkről van szó - nyilván az lesz.Sk8erPeter
-
#15275
Sk8erPeter
nagyúr
margithid
#15273
Sk8erPeter
nagyúr
válasz
margithid
#15273
üzenetére
Én most is ezt a Windows-ba beépített lehetőséget tudnám javasolni:
http://prohardver.hu/tema/flash_ssd_osszefoglalo_az_1_hsz-ben/hsz_13950-13950.html
Elvileg akár ezt is futtathatod több órán át, ha úgy tetszik, ezután megkaphatod, mi ír a legtöbbet a háttértárra. Amúgy a fentebb leírt módszert ennél specifikusabbá is lehet tenni, úgy, hogy tényleg csak kifejezetten az I/O tevékenységet monitorozod.Sk8erPeter
-
#15222
Sk8erPeter
nagyúr
Frosttide
#15221
Sk8erPeter
nagyúr
válasz
Frosttide
#15221
üzenetére
Olvasd el az előbbi eszmefuttatást, hangzottak el érvek mindkét részről, hogy érdemes-e kikapcsolni vagy sem - egyik esetben sem történik tragédia, lehet, hogy észre sem veszed, hogy épp be van-e kapcsolva vagy sem.
Persze simán lehet ilyen eset is, ahol érződik a különbség.Sk8erPeter
-
#15215
Sk8erPeter
nagyúr
Fire/SOUL/CD
#15213
Sk8erPeter
nagyúr
válasz
Fire/SOUL/CD
#15213
üzenetére
Most az a jó, hogy mindketten Microsoftos forrást linkeltünk...
Amit Te linkeltél, az Windows 7-specifikus, amit én, ott már a Windows 8-ról is szó van, és arra nem reagáltál, amit korábban felvetettem, hogy "kevert" környezetben mi a helyzet - az emberke is a videóban röviden arról beszél, hogy azért hagyják BEkapcsolva alapból a Superfetch-et Windows 8-nál, mert amennyiben már HDD is képben van (pl. nem minden töltés SSD-ről történik), akkor adott esetben lehet különbség. Elég csak egy alkalmazást alapul venni, amit a felhasználó gyakran futttat, de HDD-ről megy, és szerintem máris lehet érzékelhető különbség, hogy bizonyos fájlokat előtölt-e a memóriába, vagy sem. Igazából a használata elméletileg 8-asnál dinamikusan változhat, attól függően, van-e szükség rá.
Amúgy persze, oké, érthető, hogy legtöbb esetben nem jelent igazi, észrevehető különbséget, és ezért igazából nem nagyon kell rajta külön agyalni, hogy kell-e vagy sem (sok vizet mindenesetre az engedélyezetten hagyása biztos nem zavar). Egyébként ha valaki ezt tesztelte (biztos lehetne találni n+1 ilyen tesztet), ilyenkor legtöbbször az van, hogy egyfajta szempontnak megfelelően, túlzottan leegyszerűsítve készítik a benchmarkokat, és így kb. sosem ad sok szempontra is kiterjedő, korrekt választ egy adott kérdésre. Pedig mondjuk érdekelne ilyen, de elég ritka a normálisan elkészített teszt úgy általában.[ Szerkesztve ]
Sk8erPeter
-
#15210
Sk8erPeter
nagyúr
FollowTheORI
#15208
Sk8erPeter
nagyúr
válasz
FollowTheORI
#15208
üzenetére
Egyetértek.
(#15204) Doky586:
Jaja, jogos, ezt azért nem írtam, mert nem igazán terjedt el, ahogy írtad is, Linuxon igencsak limitált a támogatása, szóval egyelőre ez sem megfelelő alternatíva.
Amúgy most olvasom Wikipédián, hogy egyéb akadályok is vannak:
"Restrictive licensing and software patents
Microsoft has not officially released the complete exFAT file system specification and a restrictive license from Microsoft is required in order to make and distribute exFAT implementations. Microsoft also asserts software patents on exFAT which make it difficult to re-implement its functionality in a compatible way without violating a large percentage of them. This renders the implementation, distribution, and use of exFAT as a part of free or open-source operating systems or of commercial software, for which the vendors could not obtain a license from Microsoft, legally difficult, especially in countries that recognize United States software patents. Although exFAT is now widely supported in consumer electronic devices and Mac OS X, initially these could only handle FAT12/FAT16/FAT32, which formerly rendered exFAT (and flash memory formatted with it) impractical as a universal exchange format. Linux support for exFAT is still limited. As of September 2014, a working implementation under Filesystem in User space exists."Szóval sztem úgy néz ki, inkább a Microsoft gondolkodásmódjának kellene javulnia ezen a területen.
Sk8erPeter
-
#15203
Sk8erPeter
nagyúr
Fire/SOUL/CD
#15197
Sk8erPeter
nagyúr
válasz
Fire/SOUL/CD
#15197
üzenetére
"SSD-nél lényegtelen, felesleges szolgáltatás, semmilyen jelentőséggel nem bír.
"
http://channel9.msdn.com/Shows/The-Defrag-Show/Defrag-Disabling-Hibernation-Superfetch-onboard-VGA#time=05m50sNem értem, miért ne jelenthetne előnyt még SSD-nél is, de főleg az előbbi videóban is említett "kevert" felállásban (van még HDD is mellette, arról is történhet betöltés), ha ez bekapcsolva marad? A "sok kicsi sokra megy"-elv erre pont illik.
Egész idáig pont arról győzködtük a felhasználókat, hogy ne parázzanak már rá az ilyenekre. Szerintem lehet jelentősége, hogy be van-e kapcsolva, vagy sincs, épp ezért szerintem bölcsebb BEkapcsolva hagyni ezeket a szolgáltatásokat, kárt nem okoz, hasznot viszont adott esetben hozhat, még ha kis különbséget is jelent.
Szerk.: közben pont írtál - (#15202): kifejtenéd akkor, hogy mégis miért tartod feleslegesnek a szolgáltatást?[ Szerkesztve ]
Sk8erPeter
-
#15181
Sk8erPeter
nagyúr
janos666
#15180
Sk8erPeter
nagyúr
válasz
janos666
#15180
üzenetére
Jaja, vágom.
"A Windows is kezelhetne ext4-et és/vagy megnyithatná az NTFS-t a Microsoft, esetleg mindkettő támogathatna egy új filerendszert (amit vagy a Microsoft vagy valaki más indít el nyitottan). Egyik sem valószínű."
Pedig nem lenne rossz, a Microsoft mostanában a fejlesztői világban egész nyitott szemléletet képvisel, egyre inkább nyitnak a Linux-világ és az ingyenes, akár open source-dolgok felé, ami elég szimpatikus irány - lásd a C#-világban mostanában felmutatott tendenciát, meg a Visual Studio 2013 Community-változatát, ami elég sok ASP.NET-webfejlesztőnek elég sokáig elég lehet, amíg komplex tesztelési, analizálási feladatai nincsenek, addig nincs szüksége a fizetős változatra. Ha ez a gondolkodás a Microsoftnál más területre is kiterjedne, mondjuk ilyen területre is (ti. hogy nem tartanak attól, hogy ha valami full kompatibilis a Linuxszal, akkor az jelentős felhasználói réteget szippanthat el a Windows-tól), az elég hasznos lenne.Sk8erPeter
-
#15179
Sk8erPeter
nagyúr
janos666
#15178
Sk8erPeter
nagyúr
válasz
janos666
#15178
üzenetére
Hát ez igaz, csak ha valaki Linuxot és Windows-t is használ, és mindkettőn el akarja érni az adataid, valószínűleg NTFS-partíciót is létre fog hozni; az alapján, amiket írtál, igazából a köztes állapot legfeljebb egy FAT32-partíció lehetne, de ki az a vadbarom, aki ilyen partícióra akarja pakolni az adatait (fájlméretbeli és egyéb korlátok ugye...); szóval szopás, hogy így van, de bízni kell benne, hogy a Linux megfelelően kezeli az NTFS-partíciót, jobb nincs, amíg a Windows nem hajlandó támogatni az ext2/3/4/...-partíciókat, amik Linux-specifikusak.
Sk8erPeter
-
#15175
Sk8erPeter
nagyúr
janos666
#15169
Sk8erPeter
nagyúr
válasz
janos666
#15169
üzenetére
Majd erre reagálhatnál, tényleg kíváncsi vagyok, milyen problémákat tapasztaltál a GParteddel létrehozott NTFS-partícióknál. Régebben nekem is rémlik, hogy miután GParteddel végeztem ilyen műveletet, a Windows alapból elindította ezeken a partíciókon a chkdsk-et, de újabban nem tapasztaltam ilyesmit (jó, igaz, nem hoztam létre túl sokszor NTFS-partíciót így
).Sk8erPeter
-
#15166
Sk8erPeter
nagyúr
Süvi
#15164
Sk8erPeter
nagyúr
Nézd meg, mi ír az SSD-re:
http://prohardver.hu/tema/flash_ssd_osszefoglalo_az_1_hsz-ben/hsz_13950-13950.htmlSk8erPeter
-
#15149
Sk8erPeter
nagyúr
Ice&Lime
#15148
Sk8erPeter
nagyúr
válasz
Ice&Lime
#15148
üzenetére
A verzióknál semmi érdekes nincs: nálad Windows 8.1 van fent, nála pedig Windows 7, ez a verziószámozás kezdetéből is kikövetkeztethető:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832(v=vs.85).aspxA Windows 8.1-es nevű operációs rendszer a 6.3-as verziójú (nálad ezzel kezdődik a "Szabványos AHCI 1.0 Serial ATA-vezérlő" verziószáma), a Windows 7 pedig a 6.1-es (a srácnál, meg mindenkinél, akinek Windows 7-ese van, és a "Szabványos AHCI 1.0 Serial ATA-vezérlőt" használja, ez látszik a driver verziószámának kezdeténél).
Sk8erPeter
-
#15106
Sk8erPeter
nagyúr
janos666
#15094
Sk8erPeter
nagyúr
válasz
janos666
#15094
üzenetére
"Sőt, Linux alatt nem a legjobb NTFS-re (vagy akár exFAT-ra) formázni"
Ezt kifejtenéd? Miért, milyen probléma adódhat belőle?ugyan aztROSSZ --> ugyanazt JÓ... Nem adom fel soha...Szerk.: ja, most látom: (#15104):
"Tudtommal a gparted igazából szétb@ssz@ az NTFS-t (mikor piszkálja az alatta lévő partíciót) és csak megjelöli a Windows-nak, hogy majd tegye rendbe, ha legközelebb találkoznak."
Miért b@szná szét a GParted az NTFS-re formázott partíciót? Melyik verzióban tapasztaltál ilyet, vagy hol hallottad ezt? Mit kell "szétb@szás" alatt érteni?[ Szerkesztve ]
Sk8erPeter
-
#15061
Sk8erPeter
nagyúr
janos666
#15060
Sk8erPeter
nagyúr
válasz
janos666
#15060
üzenetére
"átlag otthoni felhasználónak"? Hádekéremszépenmár miről beszélünk? Neki még egy telepítés is gondot okozhat, nemhogy secure erase... Ilyen emberke inkább tényleg ne is tudjon róla, hogy létezik egyáltalán ilyen feature, még a végén kárt tesz magában.
Nyilván nem átlagfelhasználókról beszélek, hanem olyanokról, akik mondjuk tudják, hogy lehet kiírni egy bootolható iso-t pendrive-ra, aztán a Live Linux alól egy ilyen műveletet elvégezni. Ez nálam, meg nálad sem vesz igénybe többet 10 percnél (progival iso kiír a pendrive-ra, bootolandó eszköz kiválaszt, Live Linux-bootolás megvár, secure erase next-next végigkattint, picit vár, kész), szóval nem egy nagy művelet, ha az ember tudja, mit csinál.
Na mindegy, eleget csócsáltuk a témát, néha jó lehet, általában felesleges, quick format is elég, aztán punktum.Sk8erPeter
-
#15059
Sk8erPeter
nagyúr
janos666
#15053
Sk8erPeter
nagyúr
válasz
janos666
#15053
üzenetére
Első részre: asszem kicsit több jelentőséget tulajdonítottál a szőrszálhasogató megjegyzésed okán fejét falba verő smiley-mnak, mint kellett volna.
Helyesírás-részre: valóban sokkal jobb az átlagnál a helyesírásod, ezt szögezzük le. (Egyébként is figyelsz a fogalmazásodra, és aki nem összeb@ssza a szövegét, az általában kicsit igényesebben áll a dolgokhoz.) De annyiszor írtad már le az "ugyanaz" szót és társait kettő darab szóban (miközben az egy szó), hogy bocsánat, de már bökte a szemem, igen, nekem meg ez a hülyeségem, hogy helyesírás-mániás vagyok, evvan. Belső késztetés volt, nem tehetek róla!
Szakmai részre: OK, eddig nekem úgy jött le, hogy igazából ha épp amúgy is lezúznád a partíció tartalmát, és megteheted, akkor miért is ne hajthatnál végre egy secure erase-t, végül is az a rendelkezésre álló módszerek közül a leghatékonyabb megoldás. De valóban egyszerűbb lehet a quick format.[ Szerkesztve ]
Sk8erPeter
-
#15045
Sk8erPeter
nagyúr
janos666
#15041
Sk8erPeter
nagyúr
válasz
janos666
#15041
üzenetére
"Bárhogy rendezteted őket a fórummotorral, a 15001 az 15000 feletti érték marad."
No comment...
Akkor én is hadd kötekedjek, tanuld má' meg, hogy az "ugyanúgy" egyetlen szó...
Itt még régebben alul, a neked szóló OFF-részben összegyűjtöttem a rendszeres helyesírási hibáidat. Na, de ennyit a helyesírási hibákról, inkább térjünk vissza a szakmai témára, de részemről meg ezt volt muszáj. OK, szóval akkor magyarul a tanulság, hogy mégsem úgy igaz, ahogy korábban emlékeim szerint (melyek csalhatnak) sejtetni vélted, hogy a secure erase az igazi megoldás a teljesítmény-visszaállításra, hanem a teljes igazság az, hogy az erre való kényszerülés a teljesítmény visszaállítása érdekében csak bizonyos vezérlőjű SSD-knél, bizonyos firmware-rel, bizonyos csillagállás, napszak és fényviszonyok között igaz?
[ Szerkesztve ]
Sk8erPeter
-
#15039
Sk8erPeter
nagyúr
janos666
#15033
Sk8erPeter
nagyúr
válasz
janos666
#15033
üzenetére
"amivel kapcsolatban most te "idéztél" engem"
Nem téged idéztelek, hanem az ő szavait idéztem, és erre reagáltam, téged meg hivatkozási alapként említettelek (szóval nem "idéztelek"), azzal kapcsolatban, amire mintha korábban utaltál volna. (Annyira szépen hangzik ez a mondat, hogy nincs kedvem kijavítani valami közérthetőbbre.) Bevallom, most lusta vagyok visszakeresni, de emlékeim szerint azt írtad, hogy az SSD lassulása esetén a teljesítmény-helyreállítós kísérleteid közül még a secure erase bizonyult a leggyorsabbnak (ez nem meglepő) és leghatásosabbnak (kb. visszakaptad a korábbi teljesítményt). Ha nem így lenne, hát akkor sorry..."egy szál hozzászólással az övé felett"
Nálam úgy van alapból rendezve, hogy időrendben növekvő sorrendben jelennek meg a hsz.-ek (korábbiak --> újabbak), így a 15000. alatt van a 15001.
Amúgy ti a P/E számlálóról beszéltetek csak, nem a teljesítmény-visszaállítósdiról.[ Szerkesztve ]
Sk8erPeter
-
#15031
Sk8erPeter
nagyúr
mrobes
#15022
Sk8erPeter
nagyúr
válasz
mrobes
#15022
üzenetére
"Tényleg jó sokat mutat a számláló! Vajon az alvó módból való ébresztéseket is számolja?"
Nyilván mutatja, mivel alvó állapotban normális esetben kikapcsol az SSD is, hogy az se fogyasszon áramot...
Magyarul felébresztéskor meg bekapcsolod. Ergo altatáskor is van egy ki-bekapcsolás. De nem kell ezen befosni, nehogy emiatt ne használd innentől kezdve az altatás funkciót... (#15023) jakos73: és ez új volt?
[ Szerkesztve ]
Sk8erPeter
-
#15030
Sk8erPeter
nagyúr
FollowTheORI
#14990
Sk8erPeter
nagyúr
válasz
FollowTheORI
#14990
üzenetére
"Én legalábbis tuti nem fárasztanám magam ezzel.
"
A Secure Erase a Parted Magic elindítása után annyira rettentően "fárasztó", hogy kevesebb, mint 1 perc alatt (pár másodperc maga a törlés, most hozzászámoltam még az óvatos, odafigyelő kattintgatást; na jó, ha valaki ezt a videót megnézi hozzá, akkor lehet elsőre akár 5 perc is) meg lehet csinálni.(#15000) NetTom:
"Szóval abszolút elég a quick format, ami TRIM-eli a meghajtót és ezáltal "törli" az egészet + visszaállítja a teljesítményt eredetire."
janos666 emlékeim szerint azt írta, hogy az ő tapasztalata az volt, hogy a sima formázgatással nem jött vissza az SSD eredeti teljesítménye, a secure erase hatására viszont igen.[ Szerkesztve ]
Sk8erPeter
-
#14926
Sk8erPeter
nagyúr
janos666
#14925
-
#14924
Sk8erPeter
nagyúr
janos666
#14922
Sk8erPeter
nagyúr
válasz
janos666
#14922
üzenetére
"De egyrészt, amennyire én tudom (de javítsatok ki, ha tévedek - én elismerem, hogy előfordul) a legtöbb SSD nem 4k, hanem 8k "szektoros", mert 8k szokott lenni egy NAND Page (ami ha jól tudom azt jelenti, hogy ekkora egységekben írhat a vezérlő a NAND-ra, a 4k írást is vagy úgy oldja meg, hogy kiolvas 8k-t és visszaírja 4k-val módosítva, vagy alternatívaként összevár több 4k-s írást, mikor "ráér" és elfér a cache-ben)."
Nem:
http://prohardver.hu/teszt/mindent_az_ssd-krol/az_sdd_kapacitasa_es_lassulasa.html"Az SSD csak üres lap(ok)ra (4 kB-os egységek) írhatja fel az új adatokat, az érvénytelen adatokat tartalmazó lapok pedig ottmaradnak a helyükön, amíg szükség nem lesz a szabad területre. Ráadásul létezik még egy korlátozás, ami további problémát jelent: az SSD csak egy komplett blokk (512 kB, azaz 128 darab 4 kB-os lap) törlésére vagy felülírására képes."
Aztán még bőven van szó a 4 kB-os lapokról.
(#14923):
"de "félautomata" módban, hogy te adod meg a méreteket ott abban a kis alsó sávban, ami előjön, ha rálépsz... Na, ez ki is ment a fejemből, hogy ilyen is van és így is lehet over-provisioning területet hagyni.
"
Hát ezt kb. minden mai normális telepítőben elérhető partíciókezelő tudja Windows és Linux esetén egyaránt, nem kell a méretek megadásához önmagában konzolon/terminálban bűvészkedni... Ami viszont GUI-ból nem felülbírálható, az az automatikusan létrehozott System Reserved partíció mérete (ami 7-es esetén 100 MB, igazából feleslegesen sok, ebből nálam 28,1 MB van használatban).Sk8erPeter
-
#14921
Sk8erPeter
nagyúr
p.lac
#14918
Sk8erPeter
nagyúr
Igen, bocs, teljesen igazad van, azt sikerült végül elírni. Szóval nem a törlés során van TRIM (legalábbis az eredeti hsz. szerint), hanem a fájlrendszer létrehozásakor.
(#14919) janos666:
Érdekes lehet az is, hogy mi van a 7-es (6.1 SP1) GUI-ja mögött, és mi változott az efölötti Windows-okban (8.x és most már 10). Persze nem várom el, hogy mindet teszteld. Azért az elég sok tökölés lehet. Bár sok érdekesség megtudható lenne belőle (hogy kb. mi zajlik a háttérben, és mi változott ilyen tekintetben (ha egyáltalán) a különböző verziók közt)."Na meg legtöbben amúgy is telepítéskor particionálnak (kézileg vagy automatikusan), nem előre egy működő Windows alól. -> Igaz, az automata telepítős GUI-t sem teszteltem le, csakis a DISKPART-ot."
A legtöbben az automatikus particionálást választják, bevallom, többnyire engem sem érdekel a kérdés annyira, hogy ilyenkor kézzel hozzam létre a partíciókat (persze lehetne helyet spórolni, de őszintén szólva ilyenkor túl lusta vagyok ahhoz, hogy ezzel foglalkozzak, így talán szemedben szentségtöréssel egyenlő módon megelégszem a 100 MB-os System Reserved partícióval, és a maradék fennmaradó helyre a rendszerpartíciót automatikusan létrehozós módszerrel).
Szóval ja, az is érdekes lehet, hogy maga a telepítő GUI-ja ugyanazokat a műveleteket végzi-e el, ugyanazt az eszköztárat használja-e, mint maga a diskpart. 7-esnél még kb. azt feltételezném, hogy ja, de amúgy fingom sincs, a 8.x-vonalnál meg végképp nem tudom, mi változott ilyen tekintetben (annyi minden változott, hogy elképzelhetőnek/valószínűnek tartom, hogy ehhez is hozzányúltak).(#14916) Doky586:
"TRIM téma: igen, legalábbis arra szavaznék első körben. De meg lehet ezt tudományosabban is közelíteni: egy jól kidolgozott kisérlettel kimutatható melyik az igaz.."
Őőő, hát nyilván, de pontosan ez az, amire eddig senki nem tudta beáldozni az idejét... Ha neked van kedved, én nagyon kíváncsi lennék az eredményre. Sk8erPeter
-
#14915
Sk8erPeter
nagyúr
Doky586
#14914
Sk8erPeter
nagyúr
válasz
Doky586
#14914
üzenetére
Ezt írta ő is: "ugyanakkor a 4k alatti AU méretnek már érdembeli negatív hatása van".
(#14878) Doky586:
Na, tehát összességében elmondható, hogy ezek szerint Te is azt az álláspontot erősíted, hogy amennyiben nem secure erase után raktunk félre particionálatlan területet, hanem előtte azon a területen mondjuk adatok voltak, akkor mivel sima Windows-os eszközökkel történő újraparticionálás során ezek nem TRIM-elődnek, a wear leveling során kvázi statikus adatokként tilitolizódnak ide-oda, ergo olyan, mintha az SSD jobban tele lenne, mint hinnénk.DE továbbra is kérdés számomra, mi van az újabb (>7) Windows-ok háttértár-kezelős GUI-ja mögött, nincs-e TRIM, ahogy az újabb Linuxok partíciókezelőinél a partíciótörlés során...
[ Szerkesztve ]
Sk8erPeter
-
#14877
Sk8erPeter
nagyúr
FollowTheORI
#14873
Sk8erPeter
nagyúr
válasz
FollowTheORI
#14873
üzenetére
Az a baj, hogy a "majdnem" még nem meggyőző bizonyíték.
Annak ellenére, hogy én is azt tartom sokkal valószínűbbnek, hogy ezt megoldották, nem tudom elfogadni, hogy egy triviális problémalehetőséget ne szűrtek volna ki. És mint említettem, biztos megvan az oka, hogy az adat-visszaállítás nehézségekbe ütközik az SSD-nél: ha úgy lenne, hogy statikus adatnak érzékelheti a particionálatlan területen nem kinullázott adatokat, és azokat is ide-oda toszigálná, akkor valószínűleg jóval kisebb nehézségek merülnének fel."Availability of free space from Over-provision capacity"
Na ez a kérdéses, hogy kell-e az, hogy az SSD gyári szoftverével tedd félre ezt az over provisioning területet, és így jelezd az SSD felé, hogy igen, az a terület tuti nincs használatban, és bármilyen ott található, esetleg maradék, nem kinullázott terület nyugodtan írható, vagy ugyanezt "gondolja" az SSD annál a területnél is, amit csak úgy particionálatlanul hagysz, és így érdemben használható wear leveling során (inkább szívesebben tippelnék utóbbira)."unused user capacity if TRIM is present (more space = lower WA)"
Itt az unused user capacity jelentheti az akár "teljes" SSD-t kitöltő nagy partíción szabadon fennmaradt részt, "if TRIM is present" - tehát abban az esetben, ha az OS támogatja a TRIM-et, akkor nyilván a fennmaradt területet tudja TRIM-elni. Szóval ebben a szempontban semmi újdonság nincs, ezt eddig is tudtuk, hogy így működik a TRIM.Sk8erPeter
-
#14872
Sk8erPeter
nagyúr
Fire/SOUL/CD
#14870
Sk8erPeter
nagyúr
válasz
Fire/SOUL/CD
#14870
üzenetére
Akkor látom már a TRIM-mel kapcsolatos problémára érdemben soha többé nem fogsz válaszolni még külön kérésre sem... Azon az egyetlen válaszodon kívül, ahol az "SSD belső algoritmusai a teljes felületen dolgoznak, teljesen lényegtelen, hogy nincs particionálva egy terület" pont nem válasz a kérdésre, hogy vajon lehetséges-e ilyen, hogy a particionálatlan, nem kinullázott területen lévő adatokat statikus adatként érzékeli (ergo olyan, mintha jobban telítve lenne az SSD, mint gondolnánk). Nincs is róla véleményed sem, vagy csak óvatosan nem akarsz inkább mondani elhamarkodott kijelentést, hogy ne derüljön ki, hogy esetleg téves? Mert én még a téves véleményekre is kíváncsi lennék, hátha legalább ötletet ad...
Sk8erPeter
-
#14869
Sk8erPeter
nagyúr
ubyegon2
#14857
Sk8erPeter
nagyúr
válasz
ubyegon2
#14857
üzenetére
Így lehet secure erase-t csinálni nagyon egyszerűen:
http://prohardver.hu/tema/flash_ssd_osszefoglalo_az_1_hsz-ben/hsz_10556-10556.html
Ez minden adatot elpusztít. Némileg sebességproblémák is orvosolhatóak vele, de meg lehet lenni nélküle is, amennyiben nem kezdtél el lassulást érzékelni az SSD-n.Sk8erPeter
-
#14799
Sk8erPeter
nagyúr
#21078528
#14797
-
#14794
Sk8erPeter
nagyúr
RazoR
#14793
Sk8erPeter
nagyúr
Most komolyan, egy ilyen grafikon alapján mégis honnan a frászból tudjuk?
Egyszer volt kiugró érték, ami lehet, hogy nem is volt egy vészes írási mennyiség, lehet akármitől. Lehet lapozófájlba írás, lehet, hogy valamelyik megnyitott alkalmazás írt a háttértárra, ember meg nem mondja ennyiből, épp mi produkált I/O-műveletet. Egyébként meg az is sanszos, hogy tök feleslegesen aggodalmaskodsz.
De ha mégis tudni szeretnéd, egy adott mérési időszakban épp mi produkálta a legtöbb I/O műveletet, akkor ennél "kissé" szofisztikáltabb módszerekkel is mérhetsz (rengeteg módszer van rá), pölö:
http://prohardver.hu/tema/flash_ssd_osszefoglalo_az_1_hsz-ben/hsz_13950-13950.html(#14792) Emperor_ :
Nincs mit, nem para, előferdül.Sk8erPeter
-
#14789
Sk8erPeter
nagyúr
janos666
#14769
Sk8erPeter
nagyúr
válasz
janos666
#14769
üzenetére
(#14769), (#14552), (#14603), (#14766)
Bocs, hogy csak most válaszolok, kicsit sok volt a dolog mostanság, aztán meg halasztgattam a dolgot, mert a normális válaszadáshoz gondolkodóképességre is szükség van.Jó, hogy tesztelted, akkor megtudtuk, hogy a Windows diskpart eszközével sem a partíciótörlés, sem a partíció-létrehozás NEM jár TRIM-meléssel. Nagyon valószínűnek tartom, hogy ugyanígy a Linuxos partíciókezelő eszközök használata esetén sem.
Egyébként azért jobban belegondolva ebben azért van (lehet) logika: pl. elképzelhető olyan eset, hogy véletlenül törölsz partíciókat, de aztán vissza akarod állítani (van mód partícióstruktúra helyreállítására). Ekkor nem igazán járnánk jól, ha már szépen ki lenne nullázva a francba az ott található terület.
Ez alapján meg visszakapcsolódunk ahhoz, amit levezettél: ha a particionálatlan területen ott terpeszkednek az "ottmaradt" 1-esek és 0-k, és senki nem szólt az SSD-nek, hogy az a terület bizony felszabadítható, akkor az itt lévő adatot statikus, meghagyandó adatnak érzékelheti, így a wear leveling során ezt is toszigálja ide-oda. (Most csak levezettem magamnak saját szavakkal is, amit kb. írtál.)
Ez alapján tényleg kifejezetten ROSSZ lehet a particionálatlan terület meghagyása, ha nincs előtte secure erase-elve az SSD (hanem pl. egy korábbi partícióstruktúrát simán partíciókezelővel töröltünk, és létrehozogattunk újakat (vagy csak egyet), és hagytunk egy félrerakott, particionálatlan területet is, mert az eddigi elképzelések szerint az jót tesz az SSD-nek, pedig a gondolatmenet alapján nem (nem biztos)).
Ez mondjuk kiábrándító, ha valóban így van.Tényleg kíváncsi lennék, hogy van-e erre bármi áthidaló módszer, mert ha ez a levezetés igaz, akkor szerintem nagyon sokan rosszul használják az SSD-jüket, és úgy, hogy az kifejezetten káros is az élettartamra (hiszen akkor lehet, hogy a wear leveling során sokkal nagyobb adatmennyiséget kell mozgatni, mint amire számítunk, és sokkal inkább telítve lehet az SSD alacsonyabb szinten, mint arra számítunk - hiszen senki nem TRIM-elte azokat az ominózus particionálatlan területeket, ha nem volt előtte secure erase).
Meg az is valóban érdekes kérdés lehet, hogy amikor mondjuk a Samsung Magiciannel választasz le az over provisioning miatt egy adott területet, akkor vajon a progi megfelelően kommunikál-e az SSD-vel a TRIM-elési feladatokról.Sk8erPeter
-
#14783
Sk8erPeter
nagyúr
Emperor_
#14773
Sk8erPeter
nagyúr
válasz
Emperor_
#14773
üzenetére
"A hibernációt használod?
Ha nem akkor érdemes a mostani 6 GB-ról 400 MB-re csökkenteni a méretét vagy teljesen kikapcsolni. Ha valamelyik proginak kell a megléte, akkor szólni fog."
Szerintem valamit igencsak elírtál. Mégis hogyan csökkented 400 MB-ra a hibernációs fájl méretét, amikor 8 GB RAM-ja van?
A lapozófájlra meg nincs pontos mérőszám, hogy mennyire érdemes állítani, teljesen egyénfüggő lehet, bár Windows figyelmeztet is egy bizonyos méret alatt, hogy esetleg a memory dumpokat sem fogja tudni annál kisebb lapozófájl-méret esetén kiírni; sztem a 800 MB körüli, afölötti méret lehet inkább megfelelő.
Példa a figyelmeztető ablakra:
http://prohardver.hu/tema/flash_ssd_osszefoglalo_az_1_hsz-ben/hsz_9017-9017.html
Ja, de egyébként az egész írásod nem stimmel, mivel a srácnál a lapozófájl pont le van tiltva...(#14770) RazoR8402:
Miért kell egy gigantikus méretű screenshotot belinkelni, úgy, hogy látni kelljen a teljes asztalodat az összes ikonoddal, a huszonakárhány colos monitorodnak megfelelő felbontáson, miért nem lehet használni az SSDOK "Create screenshot" funkcióját (pont ezért rakta bele Fire/SOUL/CD a lehetőséget, hogy még átlagfelhasználók is tudjanak NORMÁLIS képernyőképet készíteni), meg mondjuk egy beépített Snipping Toolt, vagy Alt+Print Screen után MSPaintbe beillesztést, hogy csak az érdekes ablakról készíts screenshotot?
Ja, és miért kell Dropboxra felrakni, ahonnan úgyis előbb-utóbb törölni fogod (így a jövőben ha valaki visszakeresi a hsz.-edet, már 404-et fog kapni az arcába), ha már a PH-nak van képfeltöltő lehetősége? (Vagy ott az imgur.com...)Meg nem HDDOK (
), hanem SSDOK."Az 5 órás használat és 192 GB az így okés?"
Igen.Egyébként megvan a megfelelő magyarázatod arra, hogy letiltsd a lapozófájlt? Ha nincs, akkor kapcsold vissza, és állítsd valami tűrhető méretre, mondjuk első körben 800 MB-ra fixáld, aztán meglátod, elég-e.
[ Szerkesztve ]
Sk8erPeter
-
#14762
Sk8erPeter
nagyúr
Vakegérke
#14761
Sk8erPeter
nagyúr
válasz
Vakegérke
#14761
üzenetére
Igazából bármilyen SSD-vel elég könnyen végrehajtható egy adatújraírás...
A legbiztosabb módszer: Live Linuxot (pl. egy pendrive-ról) elindít, dd-vel (vagy valamilyen grafikus alapú eszközzel) komplett ("faltól-falig") backup készítése a TELJES eszközről egy biztos helyre, secure erase segítségével az SSD komplett törlése (kb. nullázása, pár másodperces folyamat), majd a teljes backup visszaállítása az SSD-re (szintén dd-vel), és kész.
A backupnál nyilván oda kell figyelni, hogy tényleg mindent lementsünk.
Simán fájlkezelővel is át lehet persze másolni egyik helyről a másikra backup gyanánt a fájlokat, de számomra a dd-zés egyszerűbb, biztosabb és "költséghatékonyabb".Aztán biztos vannak még ilyen egyszerűbb SSD refresher toolok, én ilyeneket nem ismerek, hátha majd Fire/SOUL/CD tud ajánlani ilyet.
[ Szerkesztve ]
Sk8erPeter
-
#14759
Sk8erPeter
nagyúr
Sk8erPeter
#14757
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#14757
üzenetére
A Samsung SSD 840 EVO Performance Restoration Software segítségével történő firmware-frissítés ÉS adatújraírás előtti (EXT0BB6Q) és utáni (EXT0CB6Q) eredmények összehasonlítása (FONTOS a félreértések/téves tájékoztatások elkerülése érdekében: önmagában a firmware-frissítés nem oldaná meg a sebességproblémákat, kell hozzá az adatok újraírása is, ezt jelen esetben elvégzi a Performance Restoration szoftver, de vadiúj SSD esetén ez az "adatfrissítés" szükségtelen, ehhez elég lenne egy szimpla firmware-frissítés is, hiszen itt még nincsenek adatok sem, amiket újra kellene írni (ugyanez vonatkozik egy viszonylag új SSD-re, amin nincsenek 1 hónapnál régebbi adatok)):
===============================================
HDDScan 3.3
ELŐTTE:
UTÁNA:
===============================================
HDTach 3.0.4.0
Quick bench (8 MB zones)
ELŐTTE:
UTÁNA:
Long bench (32 MB zones)
ELŐTTE:
UTÁNA:
===============================================
SSD Read Speed Tester 2.04 (overclock.net)
Érdemes nézni a napok számát (Age (days)) az első oszlopban, az alapján elég egyértelműen az látszik, hogy a régebbi adatok kiolvasása a leglassabb.
(2-2 kép lesz, a bal oldalt látható, sebesség szerint rendezett (Rate (MB/s) oszlop) táblázat aljára és tetejére görgetve is készítettem screenshotot.)ELŐTTE:
UTÁNA:
A konklúzió igazából annyi, hogy mivel a régi firmware rosszul működött, a régi adatok kiolvasásának sebességében drasztikus visszaesések voltak, és jót tett a Performance Restoration szoftver segítségével történő adatújraírás, mert a sebességek nagyjából kiegyenlítődtek.
A firmware-frissítés azért szükséges, hogy - amennyiben az új firmware jól működik - a jövőben ne forduljanak elő a régi firmware esetén jelentkező, rossz számításokból adódó problémák, lassulások az 1 hónapnál régebbi adatok esetében.[ Szerkesztve ]
Sk8erPeter
-
#14757
Sk8erPeter
nagyúr
Fire/SOUL/CD
#14756
Sk8erPeter
nagyúr
válasz
Fire/SOUL/CD
#14756
üzenetére
Igen, tudom, miről szólt az egész firmware-rel kapcsolatos mizéria.
Értettem, amit mondasz, csak szórakoztam, na. Amúgy konkrétan arra értettem, hogy a régi firmware okozta a degradálódást, és ahhoz van köze. Elég hosszasan és régóta van már szó a problémáról, pl. Balage76 itt elég hosszasan leírta, mi miatt is jelentkezett a hibajelenség:
http://prohardver.hu/tema/flash_ssd_osszefoglalo_az_1_hsz-ben/hsz_14044-14044.htmlAmúgy persze, tök világos, amit mondasz, hogy önmagában a firmware-frissítés nyilván nem javítja meg a sebességet, mivel itt "csak" arról van szó, hogy egy rosszul működő algoritmus hibáit javítja ki az új firmware, magyarul a frissítés után nem lesz a korábban jelentkező rossz számolás, DE ettől még a sebesség nem áll helyre. Szóval például ha valaki egy "problémás" (nem épp most kibontott, hanem régi adatoknál jelentkező, lassú olvasási problémákkal küszködő) SSD esetében szimplán frissítené a firmware-t azzal a módszerrel, ahogy Te szoktad az új SSD-knél (ti. hogy a Performance Restorationt kihagyod, mivel tök értelmetlen lenne esetedben, így csak a firmware-t frissíted, és kész), akkor a sebesség NEM állna helyre. Ahhoz, hogy a régi adatok olvasása ne történjen olyan lassan, szükség van az adatok újraírására (és végeredmény tekintetében mindegy, hogy ez a Performance Restoration szoftverrel, vagy más szoftverrel történik ez meg (persze olyannal, ami szintén helyesen ír újra mindent)).
Egyébként én is megcsináltam faterom SSD-jén a firmware-frissítést ÉS adat-újraírást a Performance Restorationnel, elég jelentős a különbség ott is (újfent, csak a tisztánlátás kedvéért, másoknak: az adat-újraírás miatt, nem a firmware-frissítés miatt javult a sebesség, önmagában a firmware-frissítés nem oldotta volna meg!
), majd berakok én is képeket csak az érdekesség kedvéért.Ja, engem még mindig érdekelne a véleményed arról az eszmecseréről, amit folytattunk janos666-tal arról, hogy lehet, hogy nem feltétlenül jó a particionálatlan terület meghagyása ([link] (amire mindjárt reagálok
)), mert elviekben akár elképzelhető, hogy a particionálatlan, de nem secure erase-elt területen olyan, mintha statikus adatok lennének. (Erre végül már nem reagáltál, pedig sztem érdekes a téma. )[ Szerkesztve ]
Sk8erPeter
-
#14755
Sk8erPeter
nagyúr
Fire/SOUL/CD
#14754
Sk8erPeter
nagyúr
válasz
Fire/SOUL/CD
#14754
üzenetére
A régi firmware-nek eléggé van köze hozzá, mivel konkrétan az okozta, hogy ekkora különbségek voltak.
(Igen, az újraírástól javult meg, de attól még... )[ Szerkesztve ]
Sk8erPeter
-
#14550
Sk8erPeter
nagyúr
Fire/SOUL/CD
#14538
Sk8erPeter
nagyúr
válasz
Fire/SOUL/CD
#14538
üzenetére
Ez alapján, amiket írtál, igenis hasznos a particionálatlan terület - pontosabban ideális esetben így lenne. DE mi a helyzet azzal (erre a részre nem reagáltál), ami az eredeti felvetés volt janos666 részéről, majd később még alaposabban elmagyarázta, hogy esetleg egy újraparticionálás, majd szándékosan egy maradék particionálatlan terület meghagyása során a TRIM-parancs küldésének kihagyása miatt az SSD-vezérlő azt "gondolhatja", hogy pl. épp a wear leveling esetén a particionálatlan, nem "kinullázott" területen lévő adatokat is ide-oda kell mozgatni - ez így szélsőséges esetben kvázi olyan, mintha mondjuk tele lenne az SSD, mert mindent mozgatnia kell. Hiszen ha ez így van/lenne, azt feltételezi az SSD-vezérlő, hogy ott kb. statikus adatok vannak, hisz' ezek nem lettek kinullázva, mert az OS nem küldött neki TRIM-parancsot.
DE ez alapján elvileg persze a helyzet, ha egy secure erase után hagy az ember particionálatlan területet, mert akkor az a terület ki lett "nullázva", semmi gond, simán írható a terület.Ezzel viszont nekem az volt a gondom, hogy ilyen alapon a particionálatlan terület tényleg értelmetlen lenne, hiszen ha így működne, ez esetben többet ártana, mint használna. Tehát ilyen alapon tényleg sokkal értelmesebb lenne egy óriáspartíciót tartani az SSD-n élettartam szempontjából, ahogy janos666 írta, és figyelni arra, hogy ne tudd teleírni (ez ellen akár gondolom szoftveresen is tudna védekezni az ember, hogy elzár "magától" egy bizonyos területet, DE mégis egyébként van rajta fájlrendszer, így TRIM-elhető). Ez alapján mindenki rosszul csinálja, aki félrerak egy területet maga elől.
Ez már csak további okoskodás, úgyhogy igazából az előbbi a lényeg, erre lennék kíváncsi, de:
továbbmenve a gondolatmenetben ilyen alapon hiába secure erase-eltünk, majd EZUTÁN hoztunk létre particionálatlan területet, a wear leveling során ide-oda tologatja az SSD az adatokat, ide-oda írogat 0-kat és 1-eseket, és amikor már arrébbtolta egy másik területre, lehet, hogy én csak azután törlök egy adatot, és így az előző, most éppen OS által nem TRIM-elgetett területen nem történik kinullázás, hiszen elvileg csak azt a területet TRIM-eli, amin van épp fájlrendszer. Így pont az a jelenség merülhet fel legközelebbi írási kísérlet során, ami eleve a TRIM-utasítás lényege, ti. hogy ne legyen szükséges az új adat beírása során egy beolvasás/módosítás/kiírás ciklus, ami kifejezetten lassíthat.(#14548)+(#14549) janos666:
Jaja, teljesen világos a gondolatmenet (nagyjából eddig is az volt), van benne logika, de fura lenne szembesülni azzal, hogy igazából a particionálatlan terület meghagyása hülyeség. És jobb egy bazinagy partíció egy fájlrendszerrel, csak rohadtul figyelni arra, hogy legyen tényleg elég szabad hely.
Ezzel kapcsolatban írogattam feljebb, igazából neked is szól, majd kukkantsd meg.
Ja, de még egy dologban nem jutottunk közös nevezőre, konkrétan a wear levelinggel kapcsolatban, hogy az általad felvázolt gondolatmenet nyomán az ide-oda tologatás miatt is gond lehet egy későbbi törlés/írás... Igazából lehet, hogy tök érthetetlen, mire akarok kilyukadni, ha az, akkor majd megpróbálom legközelebb kávé után megfogalmazni.Sk8erPeter
-
#14527
Sk8erPeter
nagyúr
janos666
#14483
Sk8erPeter
nagyúr
válasz
janos666
#14483
üzenetére
"WL ilyen szempontból nem gond. Az már az SSD dolga.
Az én aggályom csak az, hogy az SSD vezérlő biztosan tudjon róla, hogy melyik a logikailag üres LBA szektor (és így terület ennyi NAND területet).
Ha nem tudja, akkor őrizgetnie kell a szektorokban tárolt adatokat (és igen, ilyenkor a WL+GC is pakolászhatja ezeket is körbe-körbe a többi hasznos adattal együtt, ami így extra írást jelenthet)."
Az a "terület ennyi NAND-területet" gondolom "törölhet" akart lenni. Viszont ez így akkor ellentmondásos - hiszen elvileg mindkettő "az SSD dolga". Tehát ennek a logikának a mentén, amin elindultál, amennyiben a vezérlő nem tud róla, hogy az a nem particionált terület felszabadítható (mert korábban mondjuk nem volt secure erase, vagy más, ami miatt egész biztosan nem gondolja azt, hogy ott statikus adatok lennének - már amennyiben ez egyáltalán felmerülhet, és pl. a partícióstuktúra-törlés, majd újraparticionálás nem jár TRIM-parancs küldésével egy modern partíciókezelőnél), akkor a wear leveling során történő adattili-toli esetén is az említett olvasás-módosítás-írás hármas igénye miatt (mert azt mondod, a particionálatlan területet úgy érzékelheti adott esetben, mintha ott statikus adatok lennének, meg kell vizsgálnia, szükség van-e az ott lévő esetleges korábbi adatra) lassulhatna az írás.
Szóval ilyen logika alapján szerintem a wear levelingnél is lassulás lenne észlelhető.De szóljon má' bele más is.
Sztem a téma érdekes, és jól eldumálunk róla, csak úgy tűnik, nem tudjuk a megoldást. Pl. Fire/SOUL/CD, Balage76, Bodor, vagy valaki, mi a véleményetek erről a kérdésről?
[ Szerkesztve ]
Sk8erPeter
-
#14525
Sk8erPeter
nagyúr
Memora
#14523
Sk8erPeter
nagyúr
válasz
Memora
#14523
üzenetére
Azért ennyire ne parázz, támaszd meg az ellenkező oldalát az alaplapnak finoman ujjbeggyel, és nyilván ne a memóriamodul kellős közepén fejts ki erőt, és kezdd el nyomkorászni, mert akkor össze-vissza dülöngélhet nyomás közben, és az kellemetlen következményekkel járhat, hanem éppen ott, ahol az oldalsó, direkt erre kialakított lyuknál belekapaszkodik majd a modult tartó "fogantyú" (és mindkét oldalon csináld meg). Nem muszáj egyszerre bepattintani (ahhoz jó lenne 4 kéz), DE arra nagyon figyelj, hogy mindkét oldalán biztosan bepattanjon a helyére a tartókar, tehát le tudjon szorulni, mert csak akkor van a helyén, úgy biztos az érintkezés. Igazából csak ezt ronthatod el, ha nem esel neki, mint tót az anyjának, akkor nem törsz le semmit. A biztos érintkezés viszont tényleg fontos, ezért figyelj rá, hogy tényleg belekapaszkodjon rendesen az említett fogantyú (tehát az legyen függőleges állapotban a bepattintás után; különben ha nincs rendesen a helyén, és érintkezési problémák vannak, azzal tönkre lehet vágni a RAM-ot - de ne arra alapozz, hogy ez fog történni, hanem csináld meg, sikerülni fog).
(#14524): a 64 bites OS több memóriát eszik, ha pl. elfogy a fizikai RAM, és túl sok a lapozási művelet (túl sokat ír-olvas a háttértárra/-ról, akkor az lassíthatja a gépet. Kevés memóriával tehát megfontolandó a 32 bites használata. De 4 GB RAM már nem számít kevésnek, amennnyiben átlagfelhasználói (átlagos böngészési szokások, filmezés, Office-termékek használata, ilyesmi) igényekről beszélünk.
(#14512):
muszályhelyett muszáj, de amúgy nem az. A BIOS-frissítést tényleg csak akkor kell megejteni, ha a frissítés hiányából konkrét hátrányod származik, vagy esetleg van valami jelentős előnye a frissítésnek. Ha nem érint a BIOS-frissítés által érintett problémakör, akkor egyszerűen figyelmen kívül hagyhatod, hogy létezik már frissebb BIOS, mert irreleváns a szemszögedből.[ Szerkesztve ]
Sk8erPeter
-
#14481
Sk8erPeter
nagyúr
janos666
#14480
Sk8erPeter
nagyúr
válasz
janos666
#14480
üzenetére
"Bár én sem vagyok benne biztos, hogy a legtöbb particionáló program TRIM-eli vagy sem az összes LBA szektort, mikor törlöd a partícióinformációkat (pl. diskpart féle CLEAN paranccsal), mert még nem próbáltam ki, de vakon inkább azt feltételezem, hogy nem."
Na ezt tényleg érdemes lenne kideríteni, elültetted a bogarat a fülembe.
Mondjuk szerencsére én eleve secure erase után particionáltam, és hagytam üresen azt a félrerakott részt a biztonság kedvéért (kb. 10%), úgyhogy nálam ez jelenleg nem játszik. Ja, de várjál, most jut eszembe, ha az általad írt elmélet mentén indulunk el, akkor akár mégis játszhatna: van ugye a wear leveling algoritmus, ahol toszigálja ide-oda az adatokat, ami meg tök független elvileg a fájlrendszertől (mert belső "önvédelmi" célból toszigálja) a TRIM viszont elvileg nem az - most ilyen alapon a toszigálás miatt is lehetne az olvasás-módosítás-írás kombó (simán írás helyett) miatt írási lassulás az általad írtakból kiindulva. Na de akkor mi van azzal az over provisioning területtel, ami eleve felhasználó által elérhetetlen? Most már kezd számomra eléggé katyvaszos lenni az egész... Most már azt sem értem, amit eddig értettem, mert összezavartál."(A beépített kémprogramjait kigyilkoltam a telepítés során.)"
Konkrétan milyen beépített kémprogramjaira gondolsz?Sk8erPeter
-
#14479
Sk8erPeter
nagyúr
janos666
#14465
Sk8erPeter
nagyúr
válasz
janos666
#14465
üzenetére
"Ha viszonylag jól értesz a géped használatához, akkor miért hagysz partícionálatlan területet?"
Nem nagyon értem, mi az összefüggés. Én például saját magam ellen is hagyok némi particionálatlan területet. Néha jól megtömködöm a háttértárat, aztán oké, észreveszem, hogy ez így nincs rendjén, de akkor meg lehet azzal szarakodni, hogy akkor most hova is pakoljam azt a plusz szutykot, hogy felszabadítsak némi területet. Ha eleve félre van téve egy rész, akkor nincs észrevétlen teletömködés.Bevallom, a második rész, amit írtál, nekem kicsit furcsa, de ha jobban belegondolok, lehet benne valami, bár őszintén szólva ehhez mélyebben kellene ismernem az SSD-k lelkivilágát. Bár kicsit lehülyézve érzem magam.
Lehet, hogy félreértelek, de akkor azt állítod, hogy amennyiben mondjuk valaki nem egy secure erase után hagyott szabadon - szándékosan - particionálatlan területet (nálam mondjuk pontosan ez a helyzet, szóval talán mégsem vagyok annyira hülye), hanem mondjuk előtte tele volt az egész SSD adatokkal (és egy nagy partíció volt az egész), majd utána végrehajt egy teljes partícióstruktúra-törlést, majd újraparticionálást, akkor mivel a TRIM-parancs nem volt elküldve (tényleg, egyébként egy teljes partícióstruktúra-törlésnél nem küldődik ilyen egy korszerű particionáló programnál? Vagy ez már kutyulása a dolgoknak?), úgy érzékelheti az SSD, mintha ott mondjuk kvázi statikus adatok lennének, ezért olvasás-módosítás-írás trió történne, így lassabb lehetne az írás adott esetben? Szóval ezért ellenzed a partícionálatlan terület meghagyását (amennyiben nem secure erase után történt ez)?Sk8erPeter
-
#14475
Sk8erPeter
nagyúr
dealerman
#14472
Sk8erPeter
nagyúr
válasz
dealerman
#14472
üzenetére
Akkor rossz a cikk, amit olvastál, inkább olvasd ezt:
http://logout.hu/bejegyzes/fire_soul_cd/windows_7_telepitesi_utmutato_ahci_edition.html"1. Igaz, hogy csak AHCI üzemmódban támogatott a TRIM?
Igaz is, meg nem is. Nem igaz, mert a Windows 7 alapértelmezett IDE (pciide.sys) és AHCI (msahci.sys) drivere is támogatja a TRIM parancsot, SATA IDE és SATA AHCI üzemmód esetén is.
Igaz, mert az AMD/Intel stb gyártok driverei csak SATA AHCI módban támogatják a TRIM-et.
Ezen általános megállapításoktól függetlenül lehet találkozni olyan -tipikusan Intel- IDE driver-ekkel, amelyek továbbítják a TRIM-et, de legbiztosabb ellenőrizni illetve én minden esetben azt javaslom, hogy le kell cserélni az OS alap IDE driver-ére."Tanulság: figyelj rá, hogy ne rakj fel semmilyen chipset-gyűjteményes szutykot, amit az alaplapi CD-ken találsz (vagy a gyártói support-oldalon), hanem a Windows alapértelmezett, Microsoftos drivere legyen fent, és kész.
Sk8erPeter
-
#14459
Sk8erPeter
nagyúr
#21078528
#14452
Sk8erPeter
nagyúr
válasz
#21078528
#14452
üzenetére
Őőő, nem most kezdtem a szakmát, kérlek ne sorolj a "kevéssé járatosak" kategóriába, köszi.
Természetesen ismerem az openSUSE-t, Ubuntut, Debiant, stb., de még nem alakult ki nálam, hogy melyik is lenne a legkézenfekvőbb disztribúció, igazából mindegyiket meg lehet szokni, ezek között én legalábbis nem találkoztam olyan durván idegesítő és katyvaszos váltással, mint amilyen Windows-vonalon a 8-as "csempés-gépházas-de-azért-kicsit-régi-is-nem-tudom-eldönteni-legyen-jó-nagy-kutyulmány-aztán-meglátjuk"... A sok csomag, konfigurálhatóság, blabla azért a népszerű Linux-disztribúciók többségére igaz... (#14453) jakos73:
A touchpad helytelen működése miben mutatkozott meg? Amúgy nagyon fura ez a túlzott CPU-használat, ha ennyi disztribúciót kipróbáltál, ez valami nagyon egyedi lehet (vagy pár EliteBook/ProBook-gépnél jellemző valami gáz Linuxnál, fogalmam sincs)...Sk8erPeter
-
#14450
Sk8erPeter
nagyúr
Ice&Lime
#14449
Sk8erPeter
nagyúr
válasz
Ice&Lime
#14449
üzenetére
Keresgéltél ezekhez Linuxos drivereket a hivatalos oldalon? Mert pl. ehhez a ProBookhoz (4530s) vannak Linuxos driverek a HP support-oldalán. Szerk.: azért kérdezgetem, mert tényleg fura, hogy ennyire következetesen ilyen problémák voltak nálad (ettől még simán lehet, hogy általános jelenség az általad használt gépeknél), és nem tudom, kipróbáltad-e a gyári Linuxos drivereket hozzá, vagy hagytad alapon.
[ Szerkesztve ]
Sk8erPeter
Arra torrentezz, ne a 60 GB-os SSD-re.
De nagyon remélem, hogy mindezt tudod, csak játszod a kretént (bár elég sokszor volt példa rá). 
).
Önmagában szted az nem életszerű, hogy egy könyvtárban többezer fájl/alkönyvtár lenne? Pontosan így van pl. nálam is: többezer doksi van alkönyvtárak formájában a dokumentumok könyvtárában, többezer kép a képekében. Egyrészt mégis mi lenne ezzel a probléma, másrészt miért lenne jó, ha ezek a dedikált könyvtárak az SSD-n lennének? 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Magyarul felébresztéskor meg bekapcsolod. Ergo altatáskor is van egy ki-bekapcsolás. De nem kell ezen befosni, nehogy emiatt ne használd innentől kezdve az altatás funkciót... 
"
Új hozzászólás Aktív témák
Hirdetés
Pyttawrx- Tudástár Az SSD kondíciója, tények és tévhitek
- Tudástár Windows 7/8/10 SSD-vel! Hogyan is?
- Elemzés Átfogó elemzés az SSD-k természetéről
- Fujifilm X
- PlayStation 5
- Intel Core i3 / i5 / i7 / i9 10xxx "Comet Lake" és i3 / i5 / i7 / i9 11xxx "Rocket Lake" (LGA1200)
- Digitális Állampolgárság Program DÁP
- Asszociációs játék. :)
- Elemlámpa, zseblámpa
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Szólánc.
- Fűzzük össze a szavakat :)
- Vicces képek
- További aktív témák...
- AKCIÓ! 1TB Samsung 990 PRO NVMe SSD meghajtó garanciával hibátlan működéssel
- AKCIÓ! 1TB Samsung 870 QVO SATA SSD meghajtó garanciával hibátlan működéssel
- Toshiba KIOXIA XG8 1TB M.2 Gen4 NVMe SSD! 7000-5600MB/s
- Seagate Exos 7E8 8TB - SATA3, 7200 Rpm, 256MB - 100/100 -as - Eladó! 36.000.-
- Új 2TB KINGSTON XS1000 hordozható SSD , USB 3.2 Gen2, 1050/1000 MB/s, fekete .
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest